Re: json api WIP patch

On Mon, Feb 4, 2013 at 12:37 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
> On 02/04/2013 03:16 PM, Daniel Farina wrote:
>>
>> On Mon, Feb 4, 2013 at 11:38 AM, Robert Haas <robertmhaas(at)gmail(dot)com>
>> wrote:
>>>
>>> On Mon, Feb 4, 2013 at 11:10 AM, Andrew Dunstan <andrew(at)dunslane(dot)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(at)\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.

--
fdr