Re: Specific names for plpgsql variable-resolution control options?
От | David E. Wheeler |
---|---|
Тема | Re: Specific names for plpgsql variable-resolution control options? |
Дата | |
Msg-id | 06651A03-B151-4904-A8E8-1BEB2B11D548@kineticode.com обсуждение исходный текст |
Ответ на | Specific names for plpgsql variable-resolution control options? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Specific names for plpgsql variable-resolution control options?
|
Список | pgsql-hackers |
On Nov 6, 2009, at 12:21 PM, Tom Lane wrote: > I believe we had consensus that plpgsql should offer the following > three > behaviors when a name in a SQL query could refer to either a plpgsql > variable or a column from a table of the query: > * prefer the plpgsql variable (plpgsql's historical behavior) > * prefer the table column (Oracle-compatible) > * throw error for the ambiguity (to become the factory default) > and that we wanted a way for users to select one of these behaviors > at the > per-function level, plus provide a SUSET GUC to determine the default > behavior when there is not a specification in the function text. > > What we did not have was any concrete suggestions for the name or > values of the GUC, nor for the exact per-function syntax beyond the > thought that it could look something like the existing '#option dump' > modifier. > > The code is now there and ready to go, so I need a decision on these > user-visible names in order to proceed. Anyone have ideas? plpgsql_variable_conflict = fatal | oracle-compat | pg-compat ? Best, David
В списке pgsql-hackers по дате отправления: