From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | 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 01:40:50 |
Message-ID: | 28407.1258335650@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-11-16 01:52:57 | Re: Aggregate ORDER BY patch |
Previous Message | Hitoshi Harada | 2009-11-16 01:40:33 | Re: Aggregate ORDER BY patch |