From: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, 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-27 10:11:09 |
Message-ID: | m2r59sdgaq.fsf@2ndQuadrant.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> 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.
Well, we would still support positional arguments like $1 $2 etc, right?
In Pavel's example I wouldn't mind about using the "values" parameter
name but would stick to using $1.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
From | Date | Subject | |
---|---|---|---|
Next Message | Susanne Ebrecht | 2011-03-27 10:41:45 | patch for createdb section in tutorial |
Previous Message | Simon Riggs | 2011-03-27 08:02:13 | Re: Libpq PGRES_COPY_BOTH - version compatibility |