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 1v1UED-0099ze-Gq for pgsql-general@arkaria.postgresql.org; Wed, 24 Sep 2025 18:28:33 +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 1v1UEC-00F276-5U for pgsql-general@arkaria.postgresql.org; Wed, 24 Sep 2025 18:28:32 +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 1v1UEB-00F26x-7S for pgsql-general@lists.postgresql.org; Wed, 24 Sep 2025 18:28:31 +0000 Received: from fout-b6-smtp.messagingengine.com ([202.12.124.149]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1v1UE6-002fkF-0s for pgsql-general@lists.postgresql.org; Wed, 24 Sep 2025 18:28:30 +0000 Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfout.stl.internal (Postfix) with ESMTP id A01A61D0015B; Wed, 24 Sep 2025 14:28:24 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-04.internal (MEProxy); Wed, 24 Sep 2025 14:28:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aklaver.com; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1758738504; x=1758824904; bh=w89Cz9EYhTnJy9KGF1+dg+inFavYceZGdoE3n/WjxzA=; b= wyEfchiQy3+uoGuuY5/QDBDbMY8ZFrE536SfwP3g6DVniLUJeYRtwHkvaEwf8NYL iK79bWsx6aVvQolc5Mhjkp0lGCGTXSZQDZz23YnoQOvkEtRGv2kpqcyYTG6pgNgC lCiV437+yzJ3AWtYzDfLjKfuYz64ySnSsmNQXFbgFQGxx5HV1OTU9RktBzV31gvW fjZ2KAIi7t1HgtyGhLUKrJjblsMDsj6Aqn3LiJ5SXG0HATrvpSfZ2bfTOZCzLllE e84TGf7tPXWN4L/khNCNk+UOh5ZH4WjZ4rovqBsKnJReDw2aTHLlbUN/dm+3rT/w MyoAGgIMgDlxCs8juEuSvw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1758738504; x= 1758824904; bh=w89Cz9EYhTnJy9KGF1+dg+inFavYceZGdoE3n/WjxzA=; b=J A85oEa0/n0VtBz69Wp9d9/thguA4ENAa6FD/roaLNad2UPuwQ3qj4ElHyga3OjVo 6qD/rF81Qj+Hlrs0Oxhvk8JftQrbOVtlq1grN5OHOzoMiC+tgmC45YiIY//4/4jG 391fIhceeDTpA6ALgynpo0iEJ2A9b5agEttPjtYxn8Bw9zIJYKhErwt0N+qKswQX vLxoFSfuN33BTTfRLTB+ph0tV+vDFzULuyiIzs4SBi1Q4lQJb49M03h02PPVxOaj EgEycVZPyXPwXAirXH55DjLWXoYghoEzCkm4lf9d/igqLzcArs7UEFLDsTaUkIej 9FluAKqNb1WjYN1liaKSQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdeigeeffecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefkffggfgfuvfevfhfhjggtgfesthekredttddvjeenucfhrhhomheptegurhhirghn ucfmlhgrvhgvrhcuoegrughrihgrnhdrkhhlrghvvghrsegrkhhlrghvvghrrdgtohhmqe enucggtffrrghtthgvrhhnpeefgeefieeutdfggfetgefgheekjeehteeileeigfetieek jedvieeviefgheevtdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpegrughrihgrnhdrkhhlrghvvghrsegrkhhlrghvvghrrdgtohhmpdhnsggp rhgtphhtthhopeefpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehsrghmuhgvlh hmrghrkhhssehgmhgrihhlrdgtohhmpdhrtghpthhtoheprhhoughrihhgohgsuhhrghho shhmvghllhgrsehgmhgrihhlrdgtohhmpdhrtghpthhtohepphhgshhqlhdqghgvnhgvrh grlheslhhishhtshdrphhoshhtghhrvghsqhhlrdhorhhg X-ME-Proxy: Feedback-ID: i76984098:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 24 Sep 2025 14:28:23 -0400 (EDT) Message-ID: Date: Wed, 24 Sep 2025 11:28:23 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: How do I upsert depending on a second table? To: Samuel Marks Cc: Juan Rodrigo Alejandro Burgos Mella , pgsql-general References: <8f2e4644-eccd-49e8-b70b-b5c51c3aaa8c@aklaver.com> Content-Language: en-US From: Adrian Klaver In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 9/24/25 10:02, Samuel Marks wrote: > On Wed, Sep 24, 2025 at 10:13 AM Adrian Klaver > > wrote: > > Yes but it's meant to divide by zero. That cancels the whole transaction > stopping it from going through. It being a transaction lets me guarantee > that at point of update or insert [upsert] the org owner matches the > requestor. My reply was to Juan Rodrigo Alejandro Burgos Mella referencing the comment: "The insert works because there is no data in the repo table that conflicts with the entered full name. " I was pointing out that in your second example the INSERT would not happen as the org table does not have a row: name owner org0 wrong_user So the SELECT 1/COUNT(*) [...] would result in a divide by 0 error and the transaction would abort. Therefore ON CONFLICT (full_name) DO UPDATE does not apply as the INSERT never happens. I should have added previously this only applies for the 'wrong user' case. For cases where the correct name/owner exists in the org table then the INSERT and it's ON CONFLICT come into play and what happens then is dependent on whether there is an existing row in the repo with the same full_name or not. The issue I see is that the full_name is UNIQUE across all orgs and I not sure that is good idea. It would seem to me UNIQUE(org, full_name) would be better. > > I would preference a single statement (one semicolon) solution; but for > now at least this works 🤷 > -- Adrian Klaver adrian.klaver@aklaver.com