2011/3/26 Dimitri Fontaine <dimi...@2ndquadrant.fr>:
> 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.
it's maybe too hard. I agree so we should to use a function_name alias
when collision is possible. Still there are more use cases, where SQL
function is used as macro, and there a alias isn't necessary
CREATE OR REPLACE FUNCTION greatest(VARIADIC "values" anyarray)
RETURNS anyelement AS $$
SELECT max(v) FROM unnest("values")
$$ LANGUAGE sql;
Regards
Pavel
>
> 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
>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
