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

From Joel Jacobson
Subject Re: pl/pgsql feature request: shorthand for argument and local variable references
Date
Msg-id ff105ac5-8b62-4a72-9b1b-21b1d7f08d15@www.fastmail.com
Whole thread Raw
In response to Re: pl/pgsql feature request: shorthand for argument and local variable references  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: pl/pgsql feature request: shorthand for argument and local variable references
List pgsql-hackers
On Thu, Jan 6, 2022, at 17:10, Pavel Stehule wrote:
> I understand well, and I don't think it's nice.
>
> Are there some similar features in other programming languages?

It would be similar to "this" in Javascript/Java/C++,
but instead using "in" to access function parameters.

Currently, we need to prefix the parameter name if it's in conflict with a column name:

CREATE FUNCTION very_long_function_name(id int, some_value text)
RETURNS boolean
LANGUAGE sql AS $$
UPDATE some_table
SET some_value = very_long_function_name.some_value
WHERE id = very_long_function_name.id RETURNING TRUE
$$;

This is cumbersome as function names can be long, and if changing the function name,
you would need to update all occurrences of the function name in the code.

If we could instead refer to the parameters by prefixing them with "in.", we could write:

CREATE FUNCTION very_long_function_name(id int, some_value text)
RETURNS boolean
LANGUAGE sql AS $$
UPDATE some_table
SET some_value = in.some_value
WHERE id = in.id RETURNING TRUE
$$;

I think this would be nice, even if it would only work for IN parameters,
since you seldom need to access OUT parameters in the problematic WHERE-clauses anyway.
I mostly use OUT parameters when setting them on a separate row:
some_out_var := some_value;
...or, when SELECTin INTO an OUT parameter, which wouldn't be a problem.

> you can check it. It is true, so IN is usually followed by "(", but until check I am not able to say if there will be an unwanted
> shift or collision or not.

I checked gram.y, and IN_P is never followed by '.', but not sure if it could cause problems anyway, hope someone with parser knowledge can comment on this.

/Joel

pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Deduplicate min restart_lsn calculation code
Next
From: Tom Lane
Date:
Subject: Re: pl/pgsql feature request: shorthand for argument and local variable references