From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: named parameters in SQL functions |
Date: | 2009-11-16 04:46:57 |
Message-ID: | 162867790911152046v407aec9fn2c8c9dfc58856636@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2009/11/16 Andrew Dunstan <andrew(at)dunslane(dot)net>:
>
>
> Robert Haas wrote:
>>
>> On Sun, Nov 15, 2009 at 9:52 PM, Andrew Dunstan <andrew(at)dunslane(dot)net>
>> wrote:
>>
>>>
>>> Robert Haas wrote:
>>>
>>>>>
>>>>> (But having said that, an alternate qualification name is something
>>>>> that could be implemented if there were any agreement on what to use.)
>>>>>
>>>>>
>>>>
>>>> Well that is the tricky part, for sure. I would personally prefer
>>>> something like ${name} rather than a prefix, but I think you're likely
>>>> to veto that outright. So, anything reasonably short would be an
>>>> improvement over the status quo. self? this? my?
>>>>
>>>
>>> I think it would have to be a reserved word. The obvious existing keyword
>>> to
>>> use is "function" but unless I'm mistaken we'd need to move it from
>>> unreserved keyword to reserved, and I'm not sure this would justify that.
>>>
>>
>> I don't see why it would need to be a reserved word. We're not
>> changing how it gets parsed, just what it means. At any rate
>> "FUNCTION." is a 9-character prefix, which is rather longer than I
>> would prefer. PL/pgsql is a tiresomely long-winded language in
>> general, IMHO, although some of Tom's changes for 8.5 will help with
>> that.
we should to use some like #option from plpgsql too.
create or replace function verylongname(p1 integer)
returns int as $$
#option paramalias v
SELECT ... WHERE x = v.p1
Pavel
>>
>>
>>
>
> Umm, what has this to do with plpgsql? We're talking about what to use in
> pure SQL functions.
>
> If you find plpgsql tiresome, use something else. There are plenty of
> alternatives.
>
> I think the debate is likely to be pointless in any case - it seems clear
> that there are objections to anything other than funcname.paramname as a
> disambiguating mechanism, so let's just go with that. It will still be a
> considerable advance.
>
> cheers
>
> andrew
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
From | Date | Subject | |
---|---|---|---|
Next Message | Hitoshi Harada | 2009-11-16 04:49:17 | Re: Aggregate ORDER BY patch |
Previous Message | Itagaki Takahiro | 2009-11-16 04:37:33 | Re: New VACUUM FULL |