Re: json api WIP patch

On Fri, Feb 1, 2013 at 2:08 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> 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.

Normally I'd agree with you, but I think there's a complexity here
that is very frown-inducing, although I'm not positively inclined to
state that it's so great that your suggested solution is not the least
of all evils:

http://www.postgresql.org/message-id/8551.1331580169@sss.pgh.pa.us

The problem being: even though pg_operator resolves to functions in
pg_proc, they have distinct identities as far as the planner is
concerned w.r.t selectivity estimation and index selection. Already
there is a slight hazard that some ORMs that want to grow hstore
support will spell it "fetchval" and others "->". So far, infix
syntax seems to be the common default, but a minor disagreement among
ORMs or different user preferences will be destructive.

Another way to look at this is that by depriving people multiple
choices in the default install, that hazard goes away. But it also
means that, practically, CREATE OPERATOR is going to be hazardous to
use because almost all software is probably not going to assume the
existence of any non-default installed operators for JSON, and those
that do will not receive the benefit of indexes from software using
the other notation. So, I think that if one takes the 'when in doubt,
leave it out' approach you seem to be proposing, I also think that
very little profitable use of CREATE OPERATOR will take place -- ORMs
et al will choose the lowest common denominator (for good sensible
reason) and flirting with CREATE OPERATOR will probably cause
surprising plans, so I doubt it'll take hold.

--
fdr