Re: functional call named notation clashes with SQL feature

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