Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tH1hb-002e4X-Bk for pgsql-bugs@arkaria.postgresql.org; Fri, 29 Nov 2024 14:10:35 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tH1hX-008BR0-Pp for pgsql-bugs@arkaria.postgresql.org; Fri, 29 Nov 2024 14:10:33 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tGnxF-002COz-Ko for pgsql-bugs@lists.postgresql.org; Thu, 28 Nov 2024 23:29:50 +0000 Received: from mail-lj1-x235.google.com ([2a00:1450:4864:20::235]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tGnxD-0003Gf-8I for pgsql-bugs@lists.postgresql.org; Thu, 28 Nov 2024 23:29:50 +0000 Received: by mail-lj1-x235.google.com with SMTP id 38308e7fff4ca-2ffa97d99d6so14534511fa.1 for ; Thu, 28 Nov 2024 15:29:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732836586; x=1733441386; darn=lists.postgresql.org; h=mime-version:subject:references:in-reply-to:message-id:to:from:date :from:to:cc:subject:date:message-id:reply-to; bh=g80/xkhZSVhZQ3L9cMBfr6XGXbiXrC525g7GdgEXu1o=; b=eae21sQuxEVi+YiZ5tozS+EcdfJSJX7ycxHzWJQb67WvKDH3vSbGSOQMptsREgqHTj wwjhpwI41dpWvbe0coQmLRLVRmy6PRJ3B5yHxq/8SCI3G1E5qW6vGv0Sur7sD5OR9pv8 UBsy5BGfrDik+YhbSyZv9Rit3ovyvdbZzwZ9VTFlBekj7l9iaXMhQbgr9LfSO2UDgEJ1 ppcGV9tQfO7o9h3RUwp/GhqHlAaLIuZvN7XphAScDPk+1XKcJ/RyAbpTP00JmUL9pmOW 1OHnMaX1N154SRguVuB/BAHTI7f9LBvwH+tGO75zHuuD645ULtjhdms2IJ8H/GhKFCJh C7BQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732836586; x=1733441386; h=mime-version:subject:references:in-reply-to:message-id:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=g80/xkhZSVhZQ3L9cMBfr6XGXbiXrC525g7GdgEXu1o=; b=bvQzadc77TzdmZgfMAjaUGxVgxb0R99YYlS5A0hoieSFDPuvOVJ81G47u/QsEf+y8v wak2QoBx6eMOxo1QgHzJn995vqOAlufgLNv63hfdHbJJe7rmOUa8CLbJQh34A8IpqDyq 1JG/b9oFveMwvWj+5UYdKos8v59mI4de6N2lAE0gqofaIdOuCUAwp7HTLGlWagf5oiZl Nd1g5PA71l8EZ0tr8u9DOKkHNWG2qX44/91eKLga+3k25IYQlK/aLDRlyMvrYdB9+E++ Tq0G55ZYPczhQ5PPb/FHsXV+71c5KGw3LkwDwAYK+Rv700lRxV8oE1JQ2GLbXbSZ0R0k EjMw== X-Gm-Message-State: AOJu0YwbyhcQlzBvGdC9r9EpH1l6a7sQwrjVLX7oGw+bjLkB24iFTa71 aetuVbwyHbTWEqQPOjACxwpkXSS+CqsGLp9mhDYsEKyRgCkUFQ/6XBfCDSvG X-Gm-Gg: ASbGnctdPVfFxfMh701EN+mIvRIVZpyHjcSBTqlUVy3Pp9CGFpA1H6BEd+L4rvdXMDq g7+Y5b2RlWYzqvJxcB4gr1n4I6ddixD9bUrphtwXhrftCVUT7ORDCERjIxE+pzfrUI9k47BXoz0 Bn5PaUVyt3EpqpmDW66AymDasIb7T+ZUMLd1B+yK2EWpk+5kMaVau+zRagZYvkjMyQq2i+1cNFc MwNwu+zK7aW+H9fzVUOJnR0Sw4uaO+DKFUavcRpHOEjq2jvucpuK2oEPFwNGh5DVcbMEDM= X-Google-Smtp-Source: AGHT+IGGzq4RevdzQd79u5VfOzxpN/Lc1GdoVvZ/0l+pbezAEE1LOpOSJ/PP7oRXue5Hl5eS0WK1Ig== X-Received: by 2002:a05:6512:2395:b0:53d:effe:592d with SMTP id 2adb3069b0e04-53df00d94b6mr4870812e87.26.1732836585985; Thu, 28 Nov 2024 15:29:45 -0800 (PST) Received: from [192.168.1.92] ([37.204.153.118]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-53df64a07d8sm311909e87.275.2024.11.28.15.29.45 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Nov 2024 15:29:45 -0800 (PST) Date: Fri, 29 Nov 2024 02:29:39 +0300 From: Slivaev Dmitry To: pgsql-bugs@lists.postgresql.org Message-ID: <818b6dcf-f202-428e-ac7b-3d197810458d@Spark> In-Reply-To: <84b5a80c-e552-43a9-bd10-85ece52747fc@Spark> References: <84b5a80c-e552-43a9-bd10-85ece52747fc@Spark> Subject: Bug report for plpgsql X-Readdle-Message-ID: 818b6dcf-f202-428e-ac7b-3d197810458d@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="6748fce8_7fb7e0aa_257" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --6748fce8_7fb7e0aa_257 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Postrgesql version PostgreSQL 17.0 (Debian 17.0-1.pgdg120+1) on x86=5F64-pc-linux-gnu, compi= led by gcc (Debian 12.2.0-14) 12.2.0, 64-bit Description: When a=C2=A0RETURNS TABLE=C2=A0function in PL/pgSQL includes a column nam= e that matches a column in a table being targeted for an=C2=A0ON CON=46LI= CT=C2=A0clause, PostgreSQL throws an error stating that the column refere= nce is ambiguous. This happens even though the context of=C2=A0ON CON=46L= ICT=C2=A0unambiguously refers to table column names, not PL/pgSQL variabl= es. This behavior leads to unexpected errors in scenarios where the function'= s=C2=A0RETURNS TABLE=C2=A0includes columns with the same name as those in= the target table. Explicit qualification of column names in=C2=A0ON CON=46= LICT=C2=A0(e.g.,=C2=A0table.column) also fails to resolve the issue. Error Message: ERROR: column reference =22column=5Fname=22 is ambiguous DETAIL: It could refer to either a PL/pgSQL variable or a table column. CONTEXT: PL/pgSQL function some=5Ffunction() line X at SQL statement Steps to Reproduce: 1. Create a table with a unique constraint: CREATE TABLE example=5Ftable ( id uuid PRIMARY KEY DE=46AULT gen=5Frandom=5Fuuid(), column=5Fname text NOT NULL, value numeric NOT NULL, UNIQUE (column=5Fname) ); 1. Create a function that returns a table with a column name matching one= in the table: CREATE OR REPLACE =46UNCTION example=5Ffunction(p=5Fcolumn=5Fname text, p= =5Fvalue numeric) RETURNS TABLE(column=5Fname text, value numeric) LANGUAGE plpgsql AS =24=24 BEGININSERT INTO example=5Ftable (column=5Fname, value) VALUES (p=5Fcolumn=5Fname, p=5Fvalue) ON CON=46LICT (column=5Fname) DO UPDATE SET value =3D example=5Ftable.value + EXCLUDED.value RETURNING column=5Fname, value INTO column=5Fname, value; RETURN NEXT; END; =24=24; 1. Call the function: SELECT * =46ROM example=5Ffunction('test', 42); Expected Behavior: The function should execute successfully, as=C2=A0ON CON=46LICT (column=5F= name)=C2=A0unambiguously refers to the=C2=A0example=5Ftable.column=5Fname= . Actual Behavior: The function throws the following error: ERROR: column reference =22column=5Fname=22 is ambiguous DETAIL: It could refer to either a PL/pgSQL variable or a table column. --6748fce8_7fb7e0aa_257 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Postrgesql version
PostgreSQL 17.0 (Debian 17.0-1.pgdg120+1) on x86=5F64-pc-linux-gnu, =
compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit

Description:
When a&=23160;RETURNS TABLE&= =23160;function in PL/pgSQL includes a column name that matches a column = in a table being targeted for an&=23160;ON CON=46LICT&=23160= ;clause, PostgreSQL throws an error stating that the column reference is = ambiguous. This happens even though the context of&=23160;ON CON=46= LICT&=23160;unambiguously refers to table column names, not PL/pgS= QL variables.
This behavior leads to unexpected errors in scenarios where the function'= s&=23160;RETURNS TABLE&=23160;includes columns with the same= name as those in the target table. Explicit qualification of column name= s in&=23160;ON CON=46LICT&=23160;(e.g.,&=23160;table.c= olumn) also fails to resolve the issue.

Error Message:
ERROR: column reference =22column=5Fname=22 is ambiguous
DETAIL: It could refer to either a PL/pgSQL variable or a table column.
CONTEXT: PL/pgSQL function some=5Ffunction() line X at SQL statement
Steps to Repr= oduce:
  1. Create a table with a unique constraint:
CREATE TABLE example=5Ftable (
    id uuid PRIMARY KEY DE=46AULT gen=5Frandom=5Fuuid(),
    column=5Fname text NOT NULL,
    value numeric NOT NULL,
    UNIQUE (column=5Fname)
);
  1. Create a function that returns a table with a column name matching on= e in the table:
CREATE OR REPLACE =46UNCTION example=5Ffunction(p=5Fcolumn=5Fname te=
xt, p=5Fvalue numeric)
    RETURNS TABLE(column=5Fname text, value numeric)
    LANGUAGE plpgsql
AS
=24=24
BEGININSERT INTO example=5Ftable (column=5Fname, value)
    VALUES (p=5Fcolumn=5Fname, p=5Fvalue)
    ON CON=46LICT (column=5Fname)
    DO UPDATE SET value =3D example=5Ftable.value + EXCLUDED.value
    RETURNING column=5Fname, value INTO column=5Fname, value;

    RETURN NEXT;
END;
=24=24;
  1. Call the function:
SELECT * =46ROM example=5Ffunction('te=
st', 42);
Expected Beha= vior:
The functi= on should execute successfully, as&=23160;ON CON=46LICT (column=5Fn= ame)&=23160;unambiguously refers to the&=23160;example=5Ftab= le.column=5Fname.
Actual Behavior:
The function throws the following = error:
ERROR: column reference =22column=5Fname=22 is ambiguous
DETAIL: It could refer to either a PL/pgSQL variable or a table column.

--6748fce8_7fb7e0aa_257--