Re: WIP: Allow SQL-language functions to reference parameters by parameter name - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: WIP: Allow SQL-language functions to reference parameters by parameter name
Date
Msg-id m2r59sdgaq.fsf@2ndQuadrant.fr
Whole thread Raw
In response to Re: WIP: Allow SQL-language functions to reference parameters by parameter name  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: WIP: Allow SQL-language functions to reference parameters by parameter name
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:

> On Sat, Mar 26, 2011 at 5:19 PM, Dimitri Fontaine
> <dimitri@2ndquadrant.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


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Libpq PGRES_COPY_BOTH - version compatibility
Next
From: Susanne Ebrecht
Date:
Subject: [DOCS] patch for createdb section in tutorial