Property "values" missing when Inspecting InsertQuery ValuesNode

I'm having some troubles upgrading from 0.22.0 to 0.23.4, because I have a custom plugin which gets some columns as input for each database table and prevent any other column to be used as the target of an InsertQuery (this way I can silently pass { id: 42, username: "John", nonExistingColumn: "error at runtime" } as an insert value for my user table without worrying about excessive properties in the values.

I have overriden the:

protected override transformInsertQuery(_node: InsertQueryNode): InsertQueryNode

and before the upgrade I was checking if my insert query values are actual values I need to filter to remove values for non existing columns but right now I have this error saying there's no values property inside the values node:

const newValues = node.values?.kind === `ValuesNode` ? transformValues(node.values) : ...

This is due to the node.values being a OperationNode which only has:

export interface OperationNode {
    readonly kind: OperationNodeKind;
}

There used to be a ValuesNode instead, after checking for its kind "ValuesNode". But now it's just an OperationNode and I can't access values directly.

export interface ValuesNode extends OperationNode {
    readonly kind: 'ValuesNode';
    readonly values: ReadonlyArray<ValuesItemNode>;
}

Do you know how to solve?

You can use the ValuesNode.is function for the check. Then you'll have the correct type.

Ok so basically there has been a change where the nodes are considered simple "OperationNodes" and then you have to check if something is something by a guard specific for each node you'd like to check for, even if the type is not present in the target node types. I mean, it's there string-wise in the "kind" property, but that's not a discriminant type-wise, you need the guard now. Is that correct?

There have been changes from explicit node type unions to OperationNode in places where the node type can be a large number of types. Listing them all as a union no longer made sense.

If we defined OperationNode as the union of all possible nodes, then a simple node.kind === Something would work as a guard. Currently OperationNode is defined as { kind: OperationNodeKind }.

But it's been like this from the beginning. The only thing that's changed is widening of some node types from union of possibilities to OperationNode.

yeah ok so using the guard of the specific node you need is the only option but there's nothing preventing me from using another guard, one of a node which is not listed in the kind of nodes available in such OperationNode (if this case exists at all), right?