| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| 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" <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 02:45:13 |
| Message-ID: | 42265A7F-5F79-4669-87F8-45089C3E4492@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mar 25, 2011, at 9:22 PM, Joshua Berkus <josh(at)agliodbs(dot)com> wrote:
> Tom,
>
>> 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.
>
> Also, I don't understand why this would be a dump/reload issue if $1 and $2 continue to work.
>
Because an identifier that previously referred unambiguously to a column might now be ambiguous, if there is a parameter with the same name.
...Robert
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2011-03-26 03:01:45 | Re: WIP: Allow SQL-language functions to reference parameters by parameter name |
| Previous Message | Robert Haas | 2011-03-26 01:50:56 | Re: 9.1 Beta |