bugfix: add neq to comparison operators map

[soupi]

What

Some databases do not include != in their catalog's operators list. We include <> as well so that _neq can be generated for these cases.

How

1. Add it to the list

[plcplc]

You'd need to update the introspection query of v3 and v4 too if you make changes to them.

IIRC The code has to solve a similar disambiguation problem in the section that deals with implicit cast extension. There it uses LIMIT + ROW_NUMBER to emulate DISTINCT ON + ORDER BY, because cockroachdb just throws ordering of nested queries out the window (see the commentary there)

[plcplc]

Actually I think we should leave v3 and v4 completely untouched. We shouldn't service them at all unless for a security issue.

[soupi]

Removed the distinct on as we agreed that it's not necessary because each database only defines one variant of the neq operator.

[plcplc]

Is this a change we want to make? (IIRC the sanctioned name is "Native Operations").

It looks like this file hasn't been updated for some time and has collected a delta.

[soupi]

It looks like this file hasn't been updated for some time and has collected a delta.

You are right.

Is this a change we want to make? (IIRC the sanctioned name is "Native Operations").

Yes - in config v5, we split native queries to two separate fields and nest them under native operations. This particular bit represents the queries field, so it makes sense to call it native queries. The mutations field is called native mutations as well, and they both nest under the umbrella term Native Operations:

ndc-postgres/static/schema.json

Lines 956 to 978 in 39d7980

	"NativeOperations": {
	"description": "Metadata information of Native Operations.",
	"type": "object",
	"required": ["mutations", "queries"],
	"properties": {
	"queries": {
	"description": "Native Queries.",
	"allOf": [
	{
	"$ref": "#/definitions/NativeQueries"
	}
	]
	},
	"mutations": {
	"description": "Native Mutations.",
	"allOf": [
	{
	"$ref": "#/definitions/NativeMutations"
	}
	]
	}
	}
	},

[plcplc]

I think we should avoid making updates to old versions of the configuration format.

In this particular case it probably doesn't matter much either way, since the operator name mapping is just an introspection option, and all we are changing is the default value. Since we stamp out the defaults when we initialize a new configuration only people who explicitly refresh their defaults or create a new configuration with an old version number will ever see these changes.

But generally we should avoid it and prefer users upgrade ther configuration instead.

In principle this change could have to incur an update of the documentation of the configuration reference section.

[soupi]

I agree with you in principle, and changing this won't make a big difference because initialize will always output v5 configs, but it would make me feel better if we do this in this particular case :)