Re: Contains and is contained by operators of inet datatypes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andreas Karlsson <andreas(at)proxel(dot)se>
Cc: emre(at)hasegeli(dot)com, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Contains and is contained by operators of inet datatypes
Date: 2016-11-17 22:14:10
Message-ID: 4080.1479420850@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andreas Karlsson <andreas(at)proxel(dot)se> writes:
> Emre Hasegeli wrote:
>>>>> Attached patch adds <@, @>, <<@, and @>> operator symbols for inet
>>>>> datatype to replace <<=, >>=, <<, and >>.

> Nice, I am fine with this version of the patch. Setting it to ready for
> committer!

I looked at this for awhile and TBH I am not very excited about it.
I am not sure it makes anything better, but I am sure it makes things
different. People tend not to like that.

The new names might be better if we were starting in a green field,
but in themselves they are not any more mnemonic than what we had, and
what we had has been there for a lot of years. Also, if we accept both
old names and new (which it seems like we'd have to), that creates new
opportunities for confusion, which is a cost that should not be
disregarded.

The original post proposed that we'd eventually get some benefit by
being able to repurpose << and >> to mean something else, but the
time scale over which that could happen is so long as to make it
unlikely to ever happen. I think we'd need to deprecate these names
for several years, then actually remove them and have nothing there for
a few years more, before we could safely install new operators that
take the same arguments but do something different. (For comparison's
sake, it took us five years to go from deprecating => as a user operator
to starting to use it as parameter naming syntax ... and that was a
case where conflicting use could be expected to throw an error, not
silently misbehave, so we could force it with little risk of silently
breaking peoples' applications. To repurpose << and >> in this way
we would need to move much slower.)

I'm inclined to think we should just reject this patch. I'm certainly not
going to commit it without seeing positive votes from multiple people.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-11-17 22:14:17 Re: quieting DEBUG3
Previous Message Andrew Dunstan 2016-11-17 22:10:43 Re: Mail thread references in commits