Re: WIP: Allow SQL-language functions to reference parameters by parameter name

2011/3/26 Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>:
> Joshua Berkus <josh(at)agliodbs(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>