Re: named parameters in SQL functions

On Sun, Nov 15, 2009 at 8:40 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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.

It's true, but that often seems like a natural thing to do. Someone
passes you the ID of a project and you want to look up all the tasks
associated with that project and do some computation on them. Well
the task table has a project_id column, and that's also the obvious
name for the parameter. You can call it pid or my_project_id or
v_project_id or any of the other alternatives that are frequently
suggested, or just leave it unnamed and refer to it as $1, but to my
way of thinking project_id is the most natural choice.

> (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?

...Robert