"Sergio A. Kessler" <sergiokess...@gmail.com> writes: > 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.
> is this become configurable somehow, > how would I know that my code work as expected when I distribute my code ? If you're sufficiently worried about that, you can put the about-to-be-selected option syntax at the start of every function. Bear in mind though that there are many many ways for unexpected environmental settings to break functions (search_path being one of the more obvious ones); I'm not sure this one is any worse than the rest. Especially not if you test under the default 'raise error on conflict' setting. I think the other two values will mainly be useful for legacy code of one persuasion or the other. 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