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 1u9OZ9-001Jq6-9V for pgsql-general@arkaria.postgresql.org; Mon, 28 Apr 2025 13:30:36 +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 1u9OZ7-0011Ml-9n for pgsql-general@arkaria.postgresql.org; Mon, 28 Apr 2025 13:30:34 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1u9OZ6-0011Md-Kz for pgsql-general@lists.postgresql.org; Mon, 28 Apr 2025 13:30:34 +0000 Received: from mail-wr1-x436.google.com ([2a00:1450:4864:20::436]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1u9OZ5-0000cO-0S for pgsql-general@lists.postgresql.org; Mon, 28 Apr 2025 13:30:32 +0000 Received: by mail-wr1-x436.google.com with SMTP id ffacd0b85a97d-39149bccb69so4227289f8f.2 for ; Mon, 28 Apr 2025 06:30:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bowt-ie.20230601.gappssmtp.com; s=20230601; t=1745847028; x=1746451828; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=QKPHOdJ1lYuvqiluJYYCxNu0vsrqFzGQcPAOi78U2kc=; b=orb1z7g6ZbbPo0HkFkGweiVFEeKaYkflfc1J/lr6FY5d5TOUuMoyH0D7JDR7RUy7m9 5UheQGNFWqd+tHoAEw5cj950LVATVKAl/fQBlAYFcbn/38gMpIStaLjKHHPu1QyQC+8W bJ4boq3EP3yOBOvGOP5PK7arJjdiEmBns/sdHuFTve57+v1vZtBdGn4dlUHU+7SoWgzu Ys9J3I8n7OQL8Prv6Vh5He29gd86ZB3X3qwfFOUmLmJDG/HZ0WqvenEcjskT3/Y2NMRd 5bl8gu4TnSSGhgPNJ/VLietvG/TZM4ipj0Pw+C/S0CzKle7tX2QidM7TpEFuqwfVtRyM QDrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745847028; x=1746451828; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=QKPHOdJ1lYuvqiluJYYCxNu0vsrqFzGQcPAOi78U2kc=; b=m0+CGrJEtSKk9tyXubgyR4bpudSXH7qWiro8iLn7l8oFBRWitg/uFhN8C96HkQjQgL juBc10g4n43GkQ4LcKU/+tK8t91FnS6Q1cuPQp03OLhIC6jk2LV5NdzA5I+0Sfr5v4n3 5gleFDVmkyGytvRhHyQ1pUbCxHErQ/vG4q/5TyyWJMLL4v1utNUOUC8TR3J6AzW9t837 APGK9Q4pfUjx32+83LXDtjO4ZWzWXtKhfwFXeg2jF0nB4OLSBVSQ5R/RyxQUCaZercXK smjN1xuWkOS2UgGT4GhsSleBM8acgStxEi4FsKpHz8ePm6+t9tIGflSKzGd1T3WrZ2tP 2o+A== X-Gm-Message-State: AOJu0Yw6GxRJBN7ZoGTTtERrN2+ADZS/XhQNx+6EMQ2ufkcCeaDvSdaQ CDXZ1/Ku4GnoeQbKdllFBOBlAV3MLXvbibMaWvcB20T85/lhkNVQ2b5qgTn3Icvpu1rQ/SwlFky Hhs2g5tPNZwPR0HYZ/HL0QuKIZo6R9Zp1bB1F7w== X-Gm-Gg: ASbGncvrb9NKv2pWhGwttKhL4U+QsvrOWFMijbwy88HOFJD5SFGCl4zCKcjGekScUbX X98MY1hk7s3wr/+/pybf1U7kYWw0LQ3NlD7j8c1feS39ItR8ebLfN0m82pmlkPYldCQmMbz2ylg KaVgaIWytnhjxRGtqzJaTVJQhNBuqCh5Qd X-Google-Smtp-Source: AGHT+IFfaeQVC8lhS23IRKq4gQlDTYQXicWaHM+SsMZxtwQZewlfHz/co64XK7ds3r8FDVqPzWlpVXTbGUOzc4R+WQQ= X-Received: by 2002:a5d:59a4:0:b0:39c:cc7:3c97 with SMTP id ffacd0b85a97d-3a074f47fa5mr8928401f8f.50.1745847028472; Mon, 28 Apr 2025 06:30:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Peter Geoghegan Date: Mon, 28 Apr 2025 09:30:02 -0400 X-Gm-Features: ATxdqUGOgKoTqrsGI1VBILYhKUyKNBW-DntPRHitWmKC_Eat4IItwhZdoZodEwg Message-ID: Subject: Re: Upsert error "column reference is ambiguous" To: Tim Starling Cc: pgsql-general@lists.postgresql.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, Apr 28, 2025 at 12:56=E2=80=AFAM Tim Starling wrote: > Our application has an upsert method which takes the assignment > "v=3Dv+1" as a string. It is feasible to split it on the equals sign > into the destination field and expression components, but it is not > feasible to parse the expression or to require callers to supply an > AST tree for the expressions they give us. It is not feasible to > require callers to prefix all field names with the table name. You can use an alias for the target table name. Is it feasible to require callers to prefix all field names with a generic table name alias? --=20 Peter Geoghegan