On 11/17/2016 11:14 PM, Tom Lane wrote:
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 agree. The value in re-purposing them is pretty low given the long
time scales needed before that can be done.
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.
Given that I reviewed it I think you already have my vote on this.
I like the patch because it means less operators to remember for me as a
PostgreSQL user. And at least for me inet is a rarely used type compared
to hstore, json and range types which all use @> and <@.
Andreas
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
