Re: json api WIP patch - Mailing list pgsql-hackers

From Benedikt Grundmann
Subject Re: json api WIP patch
Date
Msg-id CADbMkNOENqbBxvJNWxZPLr=b=Sk_GrfsKAVq-kFxoApX-Ewsgw@mail.gmail.com
Whole thread Raw
In response to Re: json api WIP patch  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: json api WIP patch
List pgsql-hackers



On Mon, Feb 4, 2013 at 4:10 PM, 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 ;-)

As a user I would be much in favor of just functions and no additional operators if the sole difference is syntactical.  I think custom operators are much harder to remember than function names (assuming reasonably well chosen function names).

Now Robert seems to suggest that there will also be speed / planner difference which seems sad (I would have expected operators to be just syntactical sugar for specially named functions and once we are past the parser there should be no difference).


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: json api WIP patch
Next
From: Alvaro Herrera
Date:
Subject: Re: [PATCH 4/5] Add pg_xlogdump contrib module