From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Joseph Adams <joeyadams3(dot)14159(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, alvherre <alvherre(at)commandprompt(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: functional call named notation clashes with SQL feature |
Date: | 2010-06-05 14:02:38 |
Message-ID: | 4641.1275746558@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Joseph Adams <joeyadams3(dot)14159(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2010-06-05 14:32:07 | Re: functional call named notation clashes with SQL feature |
Previous Message | Randy Solomonson | 2010-06-05 12:16:58 | How to get permission to debug postgres? |