Re: Proposition to use '==' as synonym for 'IS NOT DISTINCT FROM' - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Proposition to use '==' as synonym for 'IS NOT DISTINCT FROM'
Date
Msg-id CA+TgmoZVkrG0m4si9+n+dpyw0kNFBQyhvQ1gti7exbfZaaWwGg@mail.gmail.com
Whole thread Raw
In response to Re: Proposition to use '==' as synonym for 'IS NOT DISTINCT FROM'  (Isaac Morland <isaac.morland@gmail.com>)
Responses Re: Proposition to use '==' as synonym for 'IS NOT DISTINCT FROM'
List pgsql-hackers
On Mon, Oct 28, 2019 at 7:54 AM Isaac Morland <isaac.morland@gmail.com> wrote:
> Postgres already allows != as a synonym for <>. I think having =! mean something subtly but significantly different
isa terrible idea. At a minimum we would have to remove the synonym, which would be a backwards compatibility break.
 

I certainly agree with that. I do think, though, that IS DISTINCT FROM
is a terribly verbose thing to have to write all the time.  It's not
that bad when you write a query that contains one instance of it, but
I've both seen and written queries where you need to use it a bunch of
times, and that can get really annoying. So I don't think adding an
operator that means the same thing is a bad idea.  I don't think ==
and !== would be crazy, for instance; Tom's statement that someone
might already be using == in an extension doesn't persuade me, because
(1) even if it's true it's likely to inconvenience only a very small
percentage of users and (2) the same argument can be applied to any
operator name and is more likely to apply to operator names that don't
look like line noise, and I refuse to accept the idea that we should
commit either to never adding new operators ever again, or the
competing idea that any we do add should look like line noise.

AFAICS, Tom's got the right idea about how to fix the pg_dump
schema-qualification issue, and the idea of creating an operator
notation is a separate and possibly harder problem. Whatever we need
to add to the IS [NOT] DISTINCT FROM syntax for pg_dump can just be
hard-coded, but I guess if we want new operators we'd have to run
around and update all of our built-in data types and extensions, after
the (not so easy) preliminary step of reaching agreement on how it
should all work.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [Proposal] Global temporary tables
Next
From: Robert Haas
Date:
Subject: Re: alternative to PG_CATCH