Re: WIP: Allow SQL-language functions to reference parameters by parameter name
От | Pavel Stehule |
---|---|
Тема | Re: WIP: Allow SQL-language functions to reference parameters by parameter name |
Дата | |
Msg-id | AANLkTi=ZTAfGSVN+4X+b8SW7Zbu7CRb3DXsucm3-OWWw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: WIP: Allow SQL-language functions to reference parameters by parameter name (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: WIP: Allow SQL-language functions to reference parameters by parameter name
|
Список | pgsql-hackers |
2011/3/25 Tom Lane <tgl@sss.pgh.pa.us>: > Matthew Draper <matthew@trebex.net> writes: >> Attached is a WIP patch that allows SQL-language functions to reference >> their parameters by name. > >> It uses p_post_columnref_hook, so potentially ambiguous references >> prefer the column... that seems to make the most sense, both because it >> avoids a backwards incompatibility, and it conforms with SQL's usual >> notion of assuming you mean the "nearest" name. > > Personally I'd vote for *not* having any such dangerous semantics as > that. We should have learned better by now from plpgsql experience. > I think the best idea is to throw error for ambiguous references, > period. That means you do need ways to disambiguate in both directions. > For column references you can just qualify with the table name/alias. > If the parameter reference is intended, allow qualification with the > function name. I agree with Tom. There can be GUC for controlling use or don't use a parameter names. I am for GUC, because there will be a bilion conflicts. But a talk about priorities - sql identifier or parameter is useless. 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 >
В списке pgsql-hackers по дате отправления: