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
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) |