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 1rndXL-00EGEX-QT for pgsql-sql@arkaria.postgresql.org; Fri, 22 Mar 2024 11:58:16 +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 1rndXJ-002Yt6-V3 for pgsql-sql@arkaria.postgresql.org; Fri, 22 Mar 2024 11:58:14 +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 1rndCy-002WAV-HM for pgsql-sql@lists.postgresql.org; Fri, 22 Mar 2024 11:37:13 +0000 Received: from mail-vs1-xe36.google.com ([2607:f8b0:4864:20::e36]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rndCq-005py7-Sg for pgsql-sql@lists.postgresql.org; Fri, 22 Mar 2024 11:37:11 +0000 Received: by mail-vs1-xe36.google.com with SMTP id ada2fe7eead31-47679ac2798so677902137.2 for ; Fri, 22 Mar 2024 04:37:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711107425; x=1711712225; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=IsvOdoWlLpMJMczlBJarGy88Mj6m2ix2d0K3oahS0LU=; b=Fzj80UDRIncdQmcv2QJhLLeLstJwB0XT4O6EH0/VAvuF3Pv0Gotklg6feL6vt+8NAX ZZm72bmzbE74XcIQeJz0Lv0S+/UTzpj3ZlAAWv/43wBRhPV/WqpJRPLWRlPC9FMKplAV gla7V4/dlNrWzSjGWzavMhRO4nubfbXPGjbnpgUjpO4n9HCkwtV5FtQGiSzlQWyMeLNa KiYkUI1ANbcTECnzWpEyYk6zpXE3lOH8SCCb6dkpgShQibgqA1er6txKKpRjX4faI3ls Z7vbqQShHR4HGF5ABT8meFYif0tcqGWxVjgNaefu/1VP8lQTCe2Q7OARnK/nlpBu/6mp XQVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711107425; x=1711712225; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=IsvOdoWlLpMJMczlBJarGy88Mj6m2ix2d0K3oahS0LU=; b=hNTg3Ufq25wLaJFjd/hm0Ax7qBTrfLWNFiSifSINbbSd6vQ61qjcT4c6HwyNLnuzC+ 5bEcjhc5zPBmeOn25t8WmlR0vn85U7boCtxDnWfA724e71dhovxzENHByQLteIoGo6ed ONvzxq7vi1PraX0WTjY40Q872fbFkegYXcAucnKtQAzJ6UrI3mEjmr8C7Wr1pQ+/+A+4 b+Y3ZWdm7kzt8xklQBdxWF/wqByZZhTcIG+pTcHGLFqeJuy3WsvAiMwHgJmC8TPi8jjq arBQABhiA054TmIDnorbZSNHTGB+92rjmPqcUbZ4eAEukhB8TEkt9ozRgRI2jCYXh7LT +FzA== X-Gm-Message-State: AOJu0YyUFKqCdCsHoGikWooFVKGLn1rXrgE6J79Yrny7Ryqz1pBjm57P +XSNxhtvYOQ+42Mr4HI//V3HROLbaHRJQ59hmDfdbv4PIazizreLHg6Q1kh6RCf3dxfXvKQEkln 9WeA8nI5TK6psWFoiwkd4lIzbJPjU4ceTB7o= X-Google-Smtp-Source: AGHT+IFiaUz7LW57tqhHPrSLBpuHVEgp12XgNTGh7SHp8r56Hs3Xkh9Bgn3+hbQZrH19lTeYXCw5fbWmBDzn5QX6ytA= X-Received: by 2002:a05:6102:370b:b0:476:6e59:7d2c with SMTP id s11-20020a056102370b00b004766e597d2cmr2657551vst.32.1711107424984; Fri, 22 Mar 2024 04:37:04 -0700 (PDT) MIME-Version: 1.0 From: Jamie Thompson Date: Fri, 22 Mar 2024 11:36:54 +0000 Message-ID: Subject: UPDATE with AND clarification To: pgsql-sql@lists.postgresql.org Content-Type: multipart/alternative; boundary="0000000000003d23e106143e3ebf" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000003d23e106143e3ebf Content-Type: text/plain; charset="UTF-8" Hi, Struggled to find a section about this when scanning through the docs, but awkward keywords to scan for, so apologies for duplicating a request that has very likely come through before. I'm aware a correct syntax for a multi column UPDATE is: > UPDATE tablename SET col1 = val1, col2 = val2 WHERE id = X Earlier today, I was running some sql for someone which they had submitted as: > UPDATE tablename SET col1 = val1 AND col2 = val2 WHERE id = X This returned UPDATE 1, but the row hadn't actually changed, col1 was still the old value. Please could you explain what is actually happening here? Is there a section in the docs about this? If I EXPLAIN (ANALYZE, VERBOSE) the update with the AND syntax, I can see the top level update node has 0 rows: > Update on public.tablename (cost=11.91..24.87 rows=0 width=0) (actual time=1.377..1.378 rows=0 loops=1) So why is it returning: > UPDATE 1 Is it because it's only looking at col2 and in this scenario that value was already correct? What's it doing with the first column (col1) in the SET? Thanks, hoping this can be clarified so I can help others avoid the mistake in future. --0000000000003d23e106143e3ebf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Struggled to find a section about this when scanning through the docs, = but awkward keywords to scan for, so apologies for duplicating a request th= at has very likely come through before.

I'm aware a correc= t syntax for a multi column UPDATE is:
> UPDATE tablename SET c= ol1 =3D val1, col2 =3D val2 WHERE id =3D X

Earlier today, I wa= s running some sql for someone which they had submitted as:
> UPDATE= =C2=A0tablename SET col1 =3D val1 AND col2 =3D val2 WHERE id =3D X

<= /div>This returned UPDATE 1, but the row hadn't actually changed, col1 = was still the old value.

Please could you explain what is actu= ally happening here? Is there a section in the docs about this?
If= I EXPLAIN (ANALYZE, VERBOSE) the update with the AND syntax, I can see the= top level update node has 0 rows:
> Update on public.tablename (cost= =3D11.91..24.87 rows=3D0 width=3D0) (actual time=3D1.377..1.378 rows=3D0 lo= ops=3D1)
So why is it returning:
> UPDATE 1

Is it because it's only looking at col2 and in this scenario that va= lue was already correct? What's it doing with the first column (col1) i= n the SET?

Thanks, hoping this can be clarified so I can help = others avoid the mistake in future.
--0000000000003d23e106143e3ebf--