2008/12/9 Tom Lane <tgl@sss.pgh.pa.us>:
> "Pavel Stehule" <pavel.stehule@gmail.com> writes:
>> select foo(777, three=> '{1,2,3,4,5});
>
>> it's more safe and more readable.
>
> ... and it breaks an operator that's already in use.
>
>> I did some test, and I thing so it is implementable. I had to solve
>> problem with hstore module. There is defined operator => too, what is
>> bad. But we can implemented in transformation and it should by
>> disabled via GUC, so it's solveable.
>
> What's wrong with the "expr AS parameter_name" syntax that we've
> discussed before? (And no, having a GUC that changes the meaning
> of "=>" isn't an acceptable workaround.)
>
what is acceptable workaround? I unhappy, so this symbol was used for
this minor contrib module (for this operator doesn't exists regress
test).
a) "AS" is used in diferent meaning now [rename] (SQL/XML), labels
b) when we implemented, then we blocking possible way, when ANSI SQL
generalise current behave
c) it's own syntax that will be muddly (viz a.)
d) both mayor databases has syntax name symbol value
@name = value
name => value
I am searching ways (or syntax) for two features named params, and
named values. Last are inspirated SQL/XML that is great (I know, so
your opinion is different). For export functions I need to send some
information about columns or labels into functions. So it's usable for
custom export functions, JSON implementation, maybe for
communications.
regards
Pavel Stehule
> regards, tom lane
>
