Re: json api WIP patch

On Thu, Jan 31, 2013 at 7:12 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
>> On Thu, Jan 31, 2013 at 4:20 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>>> On 01/31/2013 05:06 PM, Peter Eisentraut wrote:
>>>> I would like to not create any -> operators, so that that syntax could
>>>> be used in the future for method invocation or something similar (it's
>>>> in the SQL standard).
>
>>> This is the first time I have heard that we should stay away from this. We
>>> have operators with this name in hstore, which is why I chose it.
>
> I'm not happy about this either. It's bad enough that we're thinking
> about taking away =>, but to disallow -> as well? My inclination is to
> just say no, we're not implementing that. Even if we remove the contrib
> operators named that way, it's insane to suppose that nobody has chosen
> these names for user-defined operators in their applications.

I think it's smarter for us to ship functions, and let users wrap them
in operators if they so choose. It's not difficult for people who
want it to do it, and that way we dodge this whole mess.

The thing that was really awful about hstore's => operator is that it
was =>(text, text), meaning that if somebody else invented, say,
xstore, they could not do the same thing that hstore did without
colliding with hstore. I think we ought to have an ironclad rule that
any operators introduced in our core distribution for particular types
must have at least one argument of that type. Otherwise, we'll end up
with a free-for-all where everyone tries to grab the "good" operator
names (of which there are only a handful) for their type, and types
we're adding five years from now will be stuck with no operator names
at all, or dumb stuff like ~~~~>.

But even leaving that aside, I'm surprised to hear so many people
dismissing SQL standards compliance so blithely. We've certainly
spent a lot of blood, sweat, and tears on minor standards-compliance
issues over they years - why is it OK to not care about this
particular issue when we've spent so much effort caring about other
ones?

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