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

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Joshua Berkus <josh(at)agliodbs(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org, Matthew Draper <matthew(at)trebex(dot)net>
Subject: Re: WIP: Allow SQL-language functions to reference parameters by parameter name
Date: 2011-03-26 21:19:12
Message-ID: m2zkohd1gv.fsf@2ndQuadrant.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2011-03-26 21:26:55 Re: WIP: Allow SQL-language functions to reference parameters by parameter name
Previous Message Darren Duncan 2011-03-26 21:04:14 Re: resolving SQL ambiguity (was Re: WIP: Allow SQL-lang funcs to ref params by param name)