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