Re: named parameters in SQL functions

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/

In response to

Responses

Browse pgsql-hackers by date

  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