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