pl/pgsql feature request: shorthand for argument and local variable references - Mailing list pgsql-hackers

From Jack Christensen
Subject pl/pgsql feature request: shorthand for argument and local variable references
Date
Msg-id CAMovtNo5z_YjreoZVXoviXGTF=wsAsi4LnW_VBiR2ZmKuGqhwg@mail.gmail.com
Whole thread Raw
Responses Re: pl/pgsql feature request: shorthand for argument and local variable references  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
When arguments and other local variables in pl/pgsql functions have the same name as columns referenced in queries it is necessary to disambiguate the names. This can be done by prefixing the function name (e.g. my_func.name), using the argument number is the case of an argument (e.g. $1), or renaming the variable (e.g. _name). It is also possible to use a GUC to always use the variable or the column but that seems dangerous to me.

Prefixing names with an underscore works well enough for local variables, but when using named arguments I prefer the external name not require an underscore. I would like to suggest a standard prefix such as $ to reference a local variable or argument. $ followed by an integer already references an argument by ordinal. What if $ followed by a name meant a local reference (essentially it would expand to "my_func.")?

For example, currently I have to do something like this:

create function update_item(id int, foo int, bar text) returns void
language plpgsql as $$
begin
  update items
  set foo = update_item.foo,
    bar = update_item.bar
  where items.id = update_item.id;
end;
$$;


I would like to be able to do something like:

create function update_item(id int, foo int, bar text) returns void
language plpgsql as $$
begin
  update items
  set foo = $foo,
    bar = $bar
  where items.id = $id;
end;
$$;


Any opinions on the desirability of this feature? My C skills are rather atrophied, but from the outside it seems like a small enough change I might be able to tackle it...

Jack

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Deleting older versions in unique indexes to avoid page splits
Next
From: Tom Lane
Date:
Subject: Re: Hash support for row types