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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, Isaac Morland <isaac(dot)morland(at)gmail(dot)com>, Eugen Konkov <kes-kes(at)yandex(dot)ru>, David Fetter <david(at)fetter(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposition to use '==' as synonym for 'IS NOT DISTINCT FROM'
Date: 2019-10-28 15:20:44
Message-ID: 26329.1572276044@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Oct 28, 2019 at 10:07 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Of course neither of those ideas is as short as "==", but
>> I think we should put some weight on not breaking things.
>> I do not believe Robert's position that nobody will complain
>> if we break extensions' use of "==" just to save some typing.

> I mean, do we have to break the extensions? If we just added ==
> operators that behaved like IS NOT DISTINCT FROM to each datatype, why
> would anything get broken?

Is that the proposal? I certainly assumed that Eugen had in mind a
parser-level hack, because adding dozens of new operators and their
underlying functions would be a Lot Of Tedious Work. But I agree
that if we did it like that, it (probably) wouldn't break anything.

I'd be somewhat inclined to adopt "===" and "!===" as the standard
names, trading off one more keystroke to get to a point where we
almost certainly aren't conflicting with anybody's existing usage.

One objection to proceeding like that is that there'd be no
visible connection between a datatype's "=" and "===" operators,
removing any hope of someday optimizing, for example, "x IS NOT
DISTINCT FROM 42" into an indexscan on x. We're certainly not
very bright about these constructs today, but at least there
exists the possibility of doing better in future. I suppose
we could think about extending btree opclasses to allow for
an === entry, but that'd be another pile of work ...

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2019-10-28 15:20:48 Using multiple extended statistics for estimates
Previous Message Alvaro Herrera 2019-10-28 15:06:44 Re: update ALTER TABLE with ATTACH PARTITION lock mode