Joshua Berkus <josh@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
