Re: json api WIP patch

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.

So, please, let's get real. A "total reliance on prefix syntax" isn't
going to happen, and investigating what it would look like seems to me
just so much wasted time and effort.

cheers

andrew