I wrote:
> To clarify, what I have in mind here doesn't have any effect whatever
> on the parse tree or the execution semantics, it's just about offering
> an alternative SQL textual representation.
Continuing this thread ... if we were just trying to fix the
dump/restore issue without regard for verbosity, I think I'd propose
that we implement syntaxes like
x IS DISTINCT FROM y
x IS DISTINCT (=) FROM y
x IS DISTINCT (schema.=) FROM y
x IS NOT DISTINCT FROM y
x IS NOT DISTINCT (=) FROM y
x IS NOT DISTINCT (schema.=) FROM y
with the understanding that the parenthesized operator name is what
to use for the underlying equality comparison, and that in the absence
of any name, the parser looks up "=" (which is what it does today).
Thus the first two alternatives are precisely equivalent, as are the
fourth and fifth. Also, to support row-wise comparisons, we could
allow cases like
ROW(a,b) IS NOT DISTINCT (schema1.=, schema2.=) FROM ROW(x,y)
ruleutils.c could proceed by looking up the operator(s) normally,
and skipping the verbose syntax when they would print as just "=",
so that we don't need to emit nonstandard SQL for common cases.
I haven't actually checked to ensure that Bison can handle this,
but since DISTINCT and FROM are both fully reserved words, it seems
virtually certain that this would work without syntactic ambiguity.
It also seems relatively understandable as to what it means.
But of course, this is the exact opposite of addressing Eugen's
concern about verbosity :-(. Can we pack the same functionality
into fewer characters?
regards, tom lane
