Re: Proposition to use '==' as synonym for 'IS NOT DISTINCT FROM'

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: David Fetter <david(at)fetter(dot)org>, Eugen Konkov <kes-kes(at)yandex(dot)ru>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposition to use '==' as synonym for 'IS NOT DISTINCT FROM'
Date: 2019-10-27 16:17:58
Message-ID: 21899.1572193078@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2019-10-27 18:07:20 Re: [Proposal] Arbitrary queries in postgres_fdw
Previous Message Dmitry Dolgov 2019-10-27 15:02:28 Re: Binary support for pgoutput plugin