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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Fetter <david(at)fetter(dot)org>
Cc: 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 18:23:49
Message-ID: 2433.1572114229@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-10-26 19:03:18 Re: pg_dump compatibility level / use create view instead of create table/rule
Previous Message Tom Lane 2019-10-26 17:19:24 Re: define bool in pgtypeslib_extern.h