Re: AW: [HACKERS] Re: Subselects open issue Nr. NEW

Thomas G. Lockhart wrote:

> One possibility was to make the generalization that any operator with "!" or
> "<>" (others too?) in the operator string would be handled as a negation, and
> all others otherwise. Then, many operators would "magically" work correctly or
> intuitively, while a few, perhaps, would not behave correctly. However, imho
> this is preferable to not allowing _any_ of these, and perhaps we would learn
> over the next few months a way to tighten it up...
>
> - Tom

Since we can't tell by the 'name' of the operator what it does (it
works often, but not always) without imposing regulations on the
naming of operators...
...add a column to pg_operator to tell what kind of operator it is:

Group Examples
------- --------
EQ =
NE <>
LT <
GT >
LE <=
GE >=
OTHER <-> <?> @-@ ## *~ !== *=~ etc...

(or give the operators other attributes which can be used to find out
if we should use OR or AND when rewriting '(x,y) OP (z,q)' queries).

... and then just check what group of operator we are dealing with.
If it is "OTHER", then produce an ERROR or NOT IMPLEMENTED message.

This could be useful in other places too. I think I have seen something
about this some weeks or months ago, when somebody had problems finding
out how to select an appropriate operator, and just had to *assume*
that "=" was the equality operator in all cases (which might not always
be true, and will create hard-to-find bugs sooner or later, since
most people will never think of the possibility that someone will use
something else than '=' for equality...)

/* m */