pl/pgsql feature request: shorthand for argument and local variable references

From: Jack Christensen <jack(at)jncsoftware(dot)com>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: pl/pgsql feature request: shorthand for argument and local variable references
Date: 2020-11-17 18:04:24
Message-ID: CAMovtNo5z_YjreoZVXoviXGTF=wsAsi4LnW_VBiR2ZmKuGqhwg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-11-17 19:33:40 Re: Hash support for row types
Previous Message Peter Geoghegan 2020-11-17 17:47:02 Re: Deleting older versions in unique indexes to avoid page splits