Re: functional call named notation clashes with SQL feature

On Wed, May 26, 2010 at 9:28 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Wed, May 26, 2010 at 8:21 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> If we go with the spec's syntax I think we'd have no realistic choice
>>> except to forbid => altogether as an operator name.  (And no, I'm not
>>> for that.)
>
>> I suppose the most painful thing about doing that is that it would
>> break hstore.  Are there other commonly-used modules that rely on =>
>> as an operator name?
>
> There don't seem to be any other contrib modules that define => as an
> operator name, but I'm not sure what's out there on pgfoundry or
> elsewhere.  The bigger issue to me is not so much hstore itself as that
> this is an awfully attractive operator name for anything container-ish.
> Wasn't the JSON-datatype proposal using => for an operator at one stage?
> (The current wiki page for it doesn't seem to reflect any such idea,
> though.)  And I think I remember Oleg & Teodor proposing such an
> operator in conjunction with some GIN-related idea or other.
>
>> In spite of the difficulties, I'm reluctant to give up on it.  I
>> always thought that the "AS" syntax was a crock and I'm not eager to
>> invent another crock to replace it.  Being compatible with the SQL
>> standard and with Oracle is not to be taken lightly.
>
> Yeah, I know.  Though this could end up being one of the bits of the
> spec that we politely decline to follow, like upper-casing identifiers.
> Still, it's a good idea to think again before we've set the release
> in stone ...
>
>                        regards, tom lane
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

I didn't really consider using => for json because it would interfere
with hstore (one of the signatures is text => text returns hstore, for
instance). I am considering using -> as a json subscript operator
(which is what hstore does) as it shouldn't interfere with hstore (as
far as I know).

Here's a thought: suppose we did use the foo (name => value) syntax
for naming parameters. It could still be used in a very similar way
for hstore:

hstore(key1 => 'value1', key2 => 'value2')

One advantage here is that => wouldn't be exclusive to hstore anymore. E.g.:

json(key1 => 'value1', key2 => 'value2')

However, note that the left hand of => is an identifier here, whereas
the left hand of hstore's current => operator is either text, text[],
or hstore.

If I had to choose between => and := for parameter naming, I'd go with
:= because it seems more SQLish to me.

I wonder if the foo (name : value) syntax would be possible/desirable.
Or maybe foo ({name: value}) :-)

Joey Adams