Re: json api WIP patch

On 02/04/2013 04:19 PM, Daniel Farina wrote:
> On Mon, Feb 4, 2013 at 12:37 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
>> On 02/04/2013 03:16 PM, Daniel Farina wrote:
>>> On Mon, Feb 4, 2013 at 11:38 AM, Robert Haas <robertmhaas@gmail.com>
>>> wrote:
>>>> On Mon, Feb 4, 2013 at 11:10 AM, Andrew Dunstan <andrew@dunslane.net>
>>>> wrote:
>>>>> On 02/04/2013 10:47 AM, Robert Haas wrote:
>>>>>>
>>>>>> The SQL standards considerations seem worth thinking about, too.
>>>>>> We've certainly gone through a lot of pain working toward eliminating
>>>>>> => as an operator name, and if the SQL standard has commandeered ->
>>>>>> for some purpose or other, I'd really rather not add to the headaches
>>>>>> involved should we ever decide to reclaim it.
>>>>> OK, but I'd like to know what is going to be safe. There's no way to
>>>>> future-proof the language. I'm quite prepared to replace -> with
>>>>> something
>>>>> else, and if I do then ->> will need to be adjusted accordingly, I
>>>>> think.
>>>>>
>>>>> My suggestion would be ~> and ~>>. I know David Wheeler didn't like that
>>>>> on
>>>>> the ground that some fonts elevate ~ rather than aligning it in the
>>>>> middle
>>>>> as most monospaced fonts do, but I'm tempted just to say "then use a
>>>>> different font." Other possibilities that come to mind are +> and +>>,
>>>>> although I think they're less attractive. But I'll be guided by the
>>>>> consensus, assuming there is one ;-)
>>>> I suspect both of those are pretty safe from an SQL standards point of
>>>> view.  Of course, as Tom is often wont to point out, the SQL standards
>>>> committee sometimes does bizarre things, so nothing's perfect, but I'd
>>>> be rather shocked if any of those got tapped to mean something else.
>>>>
>>>> That having been said, I still don't see value in adding operators at
>>>> all.  Good old function call notation seems perfectly adequate from
>>>> where I sit.  Sure, it's a little more verbose, but when you try to
>>>> too hard make things concise then you end up having to explain to your
>>>> users why \ditS is a sensible thing for them to type into psql, or why
>>>> s@\W@sprintf"%%%02x",ord($&)@e in Perl.  I recognize that I may lose
>>>> this argument, but I've worked with a couple of languages where
>>>> operators can be overloaded (C++) or defined (ML) and it's just never
>>>> seemed to work out very well.  YMMV, of course.
>>> I also basically feel this way, although I know I tend more towards
>>> notational brutalism than many.  I think we shouldn't kid ourselves
>>> that non-default operators will be used, and for
>>> current-implementation reasons (that maybe could be fixed by someone
>>> determined) it's not really at the pleasure of the author to use them
>>> via CREATE OPERATOR either.
>>>
>>> So, I basically subscribe to view that we should investigate what
>>> total reliance on prefix syntax looks like.  I guess it'll make nested
>>> navigation horribly ugly, though...positively lisp-esque.  That' s one
>>> consideration hstore doesn't have that may make use of infix notations
>>> considerably more useful for json than hstore.
>>>
>>
>> We don't have the luxury of designing things like this in or out from
>> scratch. Creation of operators has been a part of PostgreSQL for a good
>> while longer than my involvement, and a great many people expect to be able
>> to use it. I can just imagine the outrage at any suggestion of removing it.
> I am only referring to referring the restriction that the planner
> can't understand that fetchval() and '->' mean the same thing for,
> say, hstore.  Hence, use of non-default CREATE OPERATOR may become
> more useful some day, instead of basically being a pitfall when
> someone reasonably thinks they could use either spelling of the same
> functionality and the optimizer will figure it out.
>
> I'm not suggesting removal of any feature.
>
> My reference to "total reliance of prefix syntax" refers only to the
> JSON operators, since the previous correspondence from Robert was
> about how function call syntax alone may be sufficient.  This phrase
> refers to the same idea he is proposing.
>
> I also included a weakness to that idea, which is that nesting in JSON
> makes the situation worse than the common compared case, hstore.



I see. OK, sorry for misunderstanding.


I suspect, BTW that mostly people will use get_path*() (or rather, its 
equivalent operator ;-) ) rather than operator chaining:
    select myjson->>'{"authors",0,"name"}'::text[];

cheers

andrew