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 1uSJNX-0063Bq-Fd for pgsql-admin@arkaria.postgresql.org; Thu, 19 Jun 2025 17:48:47 +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 1uSJNV-00DV1L-Dt for pgsql-admin@arkaria.postgresql.org; Thu, 19 Jun 2025 17:48:46 +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 1uSJNV-00DV1D-2X for pgsql-admin@lists.postgresql.org; Thu, 19 Jun 2025 17:48:45 +0000 Received: from mailout.easymail.ca ([64.68.200.34]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1uSJNT-002zKo-2C for pgsql-admin@lists.postgresql.org; Thu, 19 Jun 2025 17:48:45 +0000 Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id 1C1CEE40F6; Thu, 19 Jun 2025 17:48:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elevated-dev.com; s=easymail; t=1750355322; bh=HDiWbIxC7qN2zFIOIyMmw1lW4KRiDGVmGyxKCt4CwzU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=DjXDj/DngVg0w067dKKOK7OohRk98qvbq68m9YBkoBocLBIJTyiQEmYekeCm+dxMW G9vXmbdrH9rStYRtHzniyM/9bYTtTA6ui6YW8E61WzpO+/ymvcu/LUFYTF28H2RwW3 9Rpnf3KcsgcbPLuNLKKH6GykfJK4imfMDXunk40IN94Y7+iQHPvKCO+ALIXi0Ahx+S CQ0RMXIUY4pC74EeKD8FTAX3Wnsuaq059fvHSxEtFf6i42u0nfg2m/oYd9q4Y8qF14 SmNw4gnTRF7jOF/WoWzCEujCSBMeUinPIRxsgwdMLXgf4ShZ9YsTWrdFkZyLKuJ4M+ E9e4PKfhnTJDg== X-Virus-Scanned: Debian amavisd-new at emo08-pco.easydns.vpn Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (emo08-pco.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PEabKMcSVyp; Thu, 19 Jun 2025 17:48:41 +0000 (UTC) Received: from smtpclient.apple (165.140.184.195.ip.vcn.com [165.140.184.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id A3B8DE40AD; Thu, 19 Jun 2025 17:48:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elevated-dev.com; s=easymail; t=1750355321; bh=HDiWbIxC7qN2zFIOIyMmw1lW4KRiDGVmGyxKCt4CwzU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=o/rxlJsdFAcKDp4R2TajrnaXHSZAIzTT2at0RYHU/T5lq/VCDuVtm6wobG+YAKxuY u77Tg23Y5KF2qMc5AKKJNBWc9OV5LSZgN2ZLbwzTyCZ3ovBki1Th8pxJpP0NLr1wJd 3HW6XGWjYmYyzNjFrY5dswUVnE/eV8wXQtcZqV2weT9Rn3u4tHkdSH1vGKzDptD21n tvGLRmT7iI+6CESAKPk3SXJToAOa6tR+gN+lSyVKSGoLxbgaEewXe9roYVQ6HNiC4A 5N2Qpglwhqd77hgp3Q1+H88ZQphlt9iZ6YX7XBc8rmRzmw4yi2Iwpo/HBVduKKvx9a 2S7U9u4j5tYlg== Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.600.51.1.1\)) Subject: Re: update behavior From: Scott Ribe In-Reply-To: <0D31EA2C-9038-4C2D-A4CD-E602809F16CC@elevated-dev.com> Date: Thu, 19 Jun 2025 11:48:30 -0600 Cc: Pgsql-admin Content-Transfer-Encoding: quoted-printable Message-Id: <58598CFA-7C0F-4629-9D54-C366CEC8CCB4@elevated-dev.com> References: <75F792AF-58DF-4559-A2E8-C89060D1E94E@elevated-dev.com> <0D31EA2C-9038-4C2D-A4CD-E602809F16CC@elevated-dev.com> To: "David G. Johnston" , Tom Lane X-Mailer: Apple Mail (2.3826.600.51.1.1) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > On Jun 19, 2025, at 11:39=E2=80=AFAM, Scott Ribe = wrote: >=20 >> On Jun 19, 2025, at 11:34=E2=80=AFAM, Scott Ribe = wrote: >>=20 >>> On Jun 19, 2025, at 11:31=E2=80=AFAM, David G. Johnston = wrote: >>>=20 >>> Correct. You need a trigger to prevent the update. There is one = provided: suppress_redundant_updates_trigger() >>=20 >> Or, in my case that prompted this question, I need a WHERE clause for = the ON CONFLICT UPDATE... >=20 > Wait, should suppress_redundant_updates_trigger be used even in this = case? Would it suppress the update before the constraint checks and = invocation of the ON CONFLICT clause??? Or no, duh, this starts with an INSERT where that won't be run, there is = no UPDATE until after the constraint violation, but then at that point = it would suppress the update?