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
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 |