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-26 21:16:37
Message-ID: 25421.1572124597@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2019-10-26 14:23:49 -0400, Tom Lane wrote:
>> ... 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.

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.

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

Yeah, I think it could only be made to work sanely for underlying
operators that have the semantics of equality. The NOT DISTINCT
wrapper has the semantics

NULL vs NULL -> true
NULL vs not-NULL -> false
not-NULL vs NULL -> false
not-NULL vs not-NULL -> apply operator

and while theoretically the operator needn't be equality, those
NULL behaviors don't make much sense otherwise. (IS DISTINCT
just inverts all the results, of course.)

I suppose that we could also imagine generalizing DistinctExpr
into something that could work with other operator semantics,
but as you say, it's a bit hard to wrap ones head around what
that would look like.

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

See the other thread I cited --- right now, the underlying operator is
always "=" and it's looked up by name. Whether that ought to change
seems like a separate can o' worms.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-10-26 21:18:09 Re: pg_dump compatibility level / use create view instead of create table/rule
Previous Message Andres Freund 2019-10-26 20:56:30 Re: pg_dump compatibility level / use create view instead of create table/rule