| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr> |
| Cc: | Joshua Berkus <josh(at)agliodbs(dot)com>, 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 22:06:05 |
| Message-ID: | AANLkTingqk9KpZOzbMEfEy=a8oXyt-Nx4V2DEcgUjfRb@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Mar 26, 2011 at 5:19 PM, Dimitri Fontaine
<dimitri(at)2ndquadrant(dot)fr> wrote:
> 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.
That syntax is sufficiently unwieldly that few people will want to use
it in real life, but certainly the backward compatibility problem is
much less than with what Tom proposed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Susanne Ebrecht | 2011-03-26 22:20:41 | characters or bytes? |
| Previous Message | Jeff Janes | 2011-03-26 22:01:46 | Re: 2nd Level Buffer Cache |