On 2/6/23 09:46, Torsten Förtsch wrote:
Is there a way to prevent this from happening? I know I can use the PK
constraint name or rename the OUT variable i. The question is can this
be resolved while keeping the arbiter inference and the variable name.
CREATE TABLE x.x (
i INT PRIMARY KEY
);
CREATE OR REPLACE FUNCTION x.ins(p_i INT, OUT i INT)
LANGUAGE plpgsql AS $$
BEGIN
INSERT INTO x.x(i)
SELECT p_i
ON CONFLICT (i) DO NOTHING;
END
$$;
postgres=# select * from x.ins(1);
ERROR: column reference "i" is ambiguous
LINE 3: ON CONFLICT (i) DO NOTHING
^
DETAIL: It could refer to either a PL/pgSQL variable or a table column.
QUERY: INSERT INTO x.x(i)
SELECT p_i
ON CONFLICT (i) DO NOTHING
CONTEXT: PL/pgSQL function x.ins(integer) line 3 at SQL statement
The conflicting variable is the OUT parameter of the function.
Normally, I'd suggest to fully qualify the name but the following or
similar is a syntax error:
INSERT INTO x.x(i) AS t
SELECT p_i
ON CONFLICT (t.i) DO NOTHING;
According to the documentation in
https://www.postgresql.org/docs/current/plpgsql-implementation.html
<https://www.postgresql.org/docs/current/plpgsql-implementation.html>:
> Query parameters will only be substituted in places where they are
syntactically permissible.
See:
https://www.postgresql.org/docs/current/plpgsql-implementation.html#PLPGSQL-VAR-SUBST
for your choices.
and
> Another way to understand this is that variable substitution can only
insert data values into an SQL command; it cannot dynamically change
which database objects are referenced by the command.
After reading this I am wondering if the current behavior is actually a bug.
Thanks,
Torsten
--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx