From: | Andrew Chernow <ac(at)esilo(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: named parameters in SQL functions |
Date: | 2009-11-16 02:03:24 |
Message-ID: | 4B00B2EC.6090407@esilo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Sun, Nov 15, 2009 at 8:22 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>>> Well, if the funcname.varname gadget will work, as you suggest elsewhere it
>>> could, I think that would suffice. I had assumed that was just something in
>>> the plpgsql engine.
>
>> That gadget isn't horribly convenient for me since my function names
>> tend to be 30 or 40 characters long. I wish we had something shorter,
>> and maybe constant. But I guess that's a topic for a separate
>> (inevitably rejected) patch.
>
> You're only going to need that if you insist on choosing parameter names
> that conflict with columns of the tables the function manipulates. Even
> then, attaching column aliases to the tables could be used instead.
> I don't see that this is any different from or worse than the extra
> typing you'll incur if you insist on using 40-character table names.
>
> (But having said that, an alternate qualification name is something
> that could be implemented if there were any agreement on what to use.)
Would something like ARG.name be acceptable?
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-11-16 02:09:32 | Re: named parameters in SQL functions |
Previous Message | Tom Lane | 2009-11-16 01:52:57 | Re: Aggregate ORDER BY patch |