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 | AANLkTikF1EEw+RCwHSoX-kjneBvTxOLaXF9GUw6UP-SZ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: WIP: Allow SQL-language functions to reference parameters by parameter name (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
2011/3/25 Tom Lane <tgl@sss.pgh.pa.us>: > Pavel Stehule <pavel.stehule@gmail.com> writes: >> 2011/3/25 Tom Lane <tgl@sss.pgh.pa.us>: >>> I think the best idea is to throw error for ambiguous references, >>> period. > >> 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. > > GUCs are not tremendously helpful for problems such as this. If we > actually wanted to preserve full backwards compatibility, we'd need to > think of a way to mark SQL functions per-function as to what to do. > But I don't think that's necessary. Up to now there's been relatively > little use for naming the parameters of SQL functions, so I think there > will be few conflicts in the field if we just change the behavior. The > mess and complication we have for the comparable behavior in plpgsql > seemed necessary because of the number of existing usages that would > certainly break --- but I doubt that SQL-language functions will have > anywhere near as big a problem. should be nice some converting tool for pg_dump or pg_upgrade. It can dump SQL functions with only qualified identifiers. Pavel > > regards, tom lane >
В списке pgsql-hackers по дате отправления: