Re: Contains and is contained by operators of inet datatypes - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Contains and is contained by operators of inet datatypes
Date
Msg-id 4080.1479420850@sss.pgh.pa.us
Whole thread Raw
In response to Re: Contains and is contained by operators of inet datatypes  (Andreas Karlsson <andreas@proxel.se>)
Responses Re: Contains and is contained by operators of inet datatypes
Re: Contains and is contained by operators of inet datatypes
List pgsql-hackers
Andreas Karlsson <andreas@proxel.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



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Mail thread references in commits
Next
From: Robert Haas
Date:
Subject: Re: quieting DEBUG3