Joshua Berkus <j...@agliodbs.com> writes: >> 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. > > As a likely heavy user of this feature, I agree with Tom here. I really > don't want the column being silently preferred in SQL functions, when > PL/pgSQL functions are throwing an error. I'd end up spending hours > debugging this.
+1 I think the best choice is to only accept qualified parameter names in SQL functions (function_name.parameter_name). If a referenced table share the function's name, ERROR out and HINT to alias the table name. If we allow more than that, we're opening the door to ambiguity, bug reports, and more than that costly migrations. I don't see any benefit in having to audit all SQL functions for ambiguity on a flag day, when this could be avoided easily. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
