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

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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-26 20:51:57
Message-ID: 20191026205157.rnls5xdvlewxmovn@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2019-10-26 14:23:49 -0400, Tom Lane wrote:
> I wrote:
> > We do have some unresolved issues around how to let dump/restore
> > control the interpretation of IS [NOT] DISTINCT FROM, cf
> > https://www.postgresql.org/message-id/flat/ffefc172-a487-aa87-a0e7-472bf29735c8%40gmail.com
> > but I don't think this idea is helping with that at all.
>
> BTW, taking a step back and viewing this suggestion as "it'd be nice
> to have *some* shorter notation than IS [NOT] DISTINCT FROM", maybe
> there's a way to unify that desire with the dump/restore fix. What
> we'd really need to fix the dump/restore problem, AFAICS, is to name
> the underlying equality operator --- potentially with a schema
> qualification --- but then have some notation that says "handle NULLs
> like IS [NOT] DISTINCT FROM does". So instead of
>
> x IS NOT DISTINCT FROM y
>
> I'm vaguely imagining
>
> x = {magic} y
>
> where unlike Eugen's suggestion, "=" is the real name of the underlying
> comparison operator. For dump/restore this could be spelled verbosely
> as
>
> x OPERATOR(someplace.=) {magic} y
>
> The hard part is to figure out some {magic} annotation that is both
> short and unambiguous. We have to cover the IS DISTINCT variant, too.

Leaving the exact choice of how {magic} would look like, are you
thinking of somehow making it work for every operator, or just for some
subset? It's intriguing to have something generic, but I'm not quite
clear how that'd would work? It's not clear to me how we'd
automatically infer a sensible meaning for e.g. < etc.

And even if we just restrict it to = (and presumably <> and !=), in
which cases is this magic going to work? Would we tie it to the textual
'=', '<>' operators? btree opclass members?

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-10-26 20:56:30 Re: pg_dump compatibility level / use create view instead of create table/rule
Previous Message Tom Lane 2019-10-26 20:12:20 Re: define bool in pgtypeslib_extern.h