2008/12/9 Tom Lane <[EMAIL PROTECTED]>: > "Pavel Stehule" <[EMAIL PROTECTED]> 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 > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers