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 1sYpB6-00EJqd-1d for pgsql-novice@arkaria.postgresql.org; Tue, 30 Jul 2024 15:54:19 +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 1sYpB4-00BKl8-7X for pgsql-novice@arkaria.postgresql.org; Tue, 30 Jul 2024 15:54:18 +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 1sYpB3-00BKl0-TQ for pgsql-novice@lists.postgresql.org; Tue, 30 Jul 2024 15:54:17 +0000 Received: from mail-yb1-xb2a.google.com ([2607:f8b0:4864:20::b2a]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sYpB1-002ERo-0v for pgsql-novice@lists.postgresql.org; Tue, 30 Jul 2024 15:54:16 +0000 Received: by mail-yb1-xb2a.google.com with SMTP id 3f1490d57ef6-e087a8f18f0so516954276.2 for ; Tue, 30 Jul 2024 08:54:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722354853; x=1722959653; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=rTUO6EYBMulCFijbbEWNSzLQLhewKTfBspPaSd+Pmio=; b=U56flnE/JhxnL8tGACoEoSCYQP3pEb4Qi9R8Z95h65GDTz4XmzAlKhJSVWG3ly/S1P Z7eMaWNSgkKKZMwiIXG2+GAufsXeYzsdVC53XiYDEcxqspp96kElhaJn5AP/uOGY45MM ovPiLbSbZ8Hv2YLsvbPF6klH4GAse3JO7le1Jy0p7dDmr24udSviDSHttl1CjRzycXJt TOasztGDOPxH9azGnY+haM519bouP7buIDUQ0aOnlztSAKlb9Xs+J5RS7MCKH/x5X8zZ N4Ch5MWdQv8CKnXxF6TSXF09ECPdaxD6vasRlJvQI6EN3/OOME1UEWXp6zGI+4IIb/oi PVZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722354853; x=1722959653; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=rTUO6EYBMulCFijbbEWNSzLQLhewKTfBspPaSd+Pmio=; b=jzczNjc0Vsm/BWbilQCpAeF+u2sB3Paaxx8ubeAJIgsAY9ABs28Dg/UOGSrTm5RXLr lJFJRtp1ky3OFGPJPn3SiJI+HRc/GwperTVlF1yzj3kAygb417EXG/F7/H8mVr9H4ku6 a0AmXIsPYZHMCdcQcd+PIqUeSanJw9QEMs27/PonfuNP6BahbMcb+L5/ctXthAO6NJ0m +ptGeye0kPZ6ufJ/qd1uUHiaOEcBImrdOnqrL3DfbNR30aV1x9IXO2HkaAH2kcNs2WAR Z9a70kF35WPGp0cmBt5BBIfk6q0uUeU/9Ix0AghHJYXRxVy3NctFtBESQ8N4ZhJkfPNs aA4Q== X-Gm-Message-State: AOJu0YxIt6VL4VDyzQoTfIU8EJzCYJ5B519a6skrnIUZVo0GZl2xKMmA sRCh9/ByPn6FsZrlvrvgHHhHP5A/mHstrK9CsazsoyMQKpNGcfF82xjWqyHCClM+fDnW4veG4iz eF1q6r6NYQ1v1lr0g+LZ569iLV6gC1g== X-Google-Smtp-Source: AGHT+IFEgCI/lnB9Ss/SuTmxVMbf+G90150CvPXtDwyGWLABr2X/KdOMewA8vx6iYMm31aczyFfI261SiPivj5njfnU= X-Received: by 2002:a05:6902:908:b0:e0b:3fc7:6be1 with SMTP id 3f1490d57ef6-e0b3fc77420mr6302519276.7.1722354852982; Tue, 30 Jul 2024 08:54:12 -0700 (PDT) MIME-Version: 1.0 From: Brian McMahon Date: Tue, 30 Jul 2024 08:53:55 -0700 Message-ID: Subject: Support for on conflict ignore returning To: pgsql-novice@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000307ad0061e78fdbe" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000307ad0061e78fdbe Content-Type: text/plain; charset="UTF-8" Hi! I have a question about support / if there's plans to support a feature, I thought it would be best to send it to the "novice" mailing list because it might be a naive question that's been answered before. Is there a recommended way to achieve a ON CONFLICT DO NOTHING RETURNING so that conflicting columns still have information returned? Currently it seems like the only simple way to achieve this is with a NOOP update, so instead doing something like ON CONFLICT UPDATE SET name = EXCLUDED.name RETURNING . As I understand it, this isn't desirable as there's various potentially undesirable side effects since it's not treated as a NOOP, it's treated as an update so triggers and all sorts of internal postgres logic are invoked (which may or may not be fine for certain applications, but it's not desirable). Are there current features that support this functionality, or plans to support something like this in the future? I should probably add my use case, I need to insert a bunch of rows into the database to ensure they exist, then for all those rows I need to update corresponding tables that reference them with more data. If I can't make a query that returns the primary key, then I either need to make a subsequent query to pull all the rows from the database that weren't inserted to get the primary keys, or I need to use the unique fields that caused the conflict in the next query to update the tables that reference the table I updated, which makes things a little messier (I'd rather just work with the primary keys when possible). Thanks in advance. -- Sincerely, Brian McMahon --000000000000307ad0061e78fdbe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi!

I have a question about support / i= f there's plans to support a feature, I thought it would be best to sen= d it to the "novice" mailing list because it might be a naive que= stion that's been answered before.

Is there a = recommended way to achieve a ON CONFLICT DO NOTHING RETURNING <column>= ; so that conflicting columns still have information returned? Currently it= seems like the only simple way to achieve this is with=C2=A0a NOOP update,= so instead doing something like ON CONFLICT UPDATE SET name =3D EXCLUDED.n= ame RETURNING <column>.

As I understand it, = this isn't desirable as there's various potentially undesirable sid= e effects since it's not treated as a NOOP, it's treated as an upda= te so triggers and all sorts of internal postgres logic are invoked (which = may or may not be fine for certain applications, but it's not desirable= ).

Are there current features that support=C2= =A0this functionality, or plans to support something like this in the futur= e?

I should probably add my use case, I need to in= sert a bunch of rows into the database to ensure they exist, then for all t= hose rows I need to update corresponding tables that reference them with mo= re data. If I can't make a query that returns the primary key, then I e= ither need to make a subsequent query to pull all the rows from the databas= e that weren't inserted to get the primary keys, or I need to use the u= nique fields that caused the conflict in the next query to update the table= s that reference the table I updated, which makes things a little messier (= I'd rather just work with the primary keys when possible).
Thanks in advance.

--
Sincerely,
Brian McMa= hon
--000000000000307ad0061e78fdbe--