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

From Pavel Stehule
Subject Re: WIP: Allow SQL-language functions to reference parameters by parameter name
Date
Msg-id BANLkTinvJW8AR0TiZuPxRQ73_YZ-=9sb3w@mail.gmail.com
Whole thread Raw
In response to Re: WIP: Allow SQL-language functions to reference parameters by parameter name  (Jim Nasby <jim@nasby.net>)
Responses Re: WIP: Allow SQL-language functions to reference parameters by parameter name  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
2011/4/15 Jim Nasby <jim@nasby.net>:
> On Apr 14, 2011, at 4:20 PM, Kevin Grittner wrote:
>> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Robert Haas <robertmhaas@gmail.com> writes:
>>
>>>> So far the most promising proposal I've seen seems to be to let
>>>> id mean the parameter called id only when it can't refer to
>>>> anything in the query.
>>
>>> Yeah, I've come round to that position too.  I think allowing
>>> parameter names to be checked only after query names is probably
>>> the best answer.
>>
>> +1
>>
>> That seems the most useful and least surprising approach to me.
>
> As part of this, can we also allow specifying an alias for the function name? That would make it far less onerous to
disambiguateparameters. Unfortunately we obviously couldn't use AS as the keyword for this alias; maybe we could use
ALIASinstead? IE: 
>
> CREATE FUNCTION function_with_really_really_descriptive_name (
>  some_parameter int
> ) RETURNS int LANGUAGE SQL ALIAS fwrrdn AS $$
>        SELECT fwrrdn.some_parameter
> $$;
> --

I see this can be problem for other languages - mainly for PLpgSQL.
There should be aliases supported too. And this small feature can be
terible when somebody will try to port your code to other platforms.
Personally I am thinking, so it isn't necessary

-1

Regards

Pavel Stehule

> Jim C. Nasby, Database Architect                   jim@nasby.net
> 512.569.9461 (cell)                         http://jim.nasby.net
>
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>


pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: using a lot of maintenance_work_mem
Next
From: Tom Lane
Date:
Subject: Re: Single client performance on trivial SELECTs