Re: functional call named notation clashes with SQL feature - Mailing list pgsql-hackers

From Tom Lane
Subject Re: functional call named notation clashes with SQL feature
Date
Msg-id 4641.1275746558@sss.pgh.pa.us
Whole thread Raw
In response to Re: functional call named notation clashes with SQL feature  (Joseph Adams <joeyadams3.14159@gmail.com>)
Responses Re: functional call named notation clashes with SQL feature  (Greg Stark <gsstark@mit.edu>)
Re: functional call named notation clashes with SQL feature  ("David E. Wheeler" <david@kineticode.com>)
List pgsql-hackers
Joseph Adams <joeyadams3.14159@gmail.com> writes:
> 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')

No, that really isn't going to work: how will the parser know that the
names are not meant to match to actual named parameters of the function?
You could possibly do it with a special case for hstore() in the
grammar, but we aren't going there, because it wouldn't be extensible.

The other variant with 'key1' => 'value1' isn't a lot better.  Yes,
we could make it work since it can't possibly be name => value, but
it would be impossibly error-prone for people to use.  The assumption
that you can always replace a constant by a variable is very deeply
wired into users' thinking, but doing so would make for a radical change
in what the syntax meant.

From a usability point of view, if we adopt the spec's syntax we have to
stop allowing => for any other purpose.  Period.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Joseph Adams
Date:
Subject: Re: functional call named notation clashes with SQL feature
Next
From: Greg Stark
Date:
Subject: Re: functional call named notation clashes with SQL feature