Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pyRv6-0006z0-Pp for pgsql-admin@arkaria.postgresql.org; Mon, 15 May 2023 06:42:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pyRv5-0006cR-ME for pgsql-admin@arkaria.postgresql.org; Mon, 15 May 2023 06:42:55 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pyRv5-0006cF-Ad for pgsql-admin@lists.postgresql.org; Mon, 15 May 2023 06:42:55 +0000 Received: from mail-yw1-x112a.google.com ([2607:f8b0:4864:20::112a]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1pyRuz-002pLn-5B for pgsql-admin@lists.postgresql.org; Mon, 15 May 2023 06:42:54 +0000 Received: by mail-yw1-x112a.google.com with SMTP id 00721157ae682-55a2cb9788dso177119597b3.2 for ; Sun, 14 May 2023 23:42:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684132967; x=1686724967; h=in-reply-to:from:references:to:content-language:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to; bh=kuhq72APZ5V6gYMZ2vMrOOKLitv4gPNuJ92v7dJN2vY=; b=agfKXk0dKofnKvhp6BTtUnZhcZff8S7avk+R439e0pBLC58P2agiOCXI1A+OsAGCFp A4UFocZwM2IgDB7EYq01jiUJ0+pSgY7oLGlJ5pl8eDz1ZRZ/nfmaDSYfvX9MXCrTqx17 liP8meb87fIcRwClJAJgXAgspEytQxvXEXri2q7FiJCuacb/HwaUaZyEUCBX6TCwfRQp 82ReBvIS6QQ7Jhi/3YjddnXQWUBWPRI2Z/uIDtiXc7flIghk6BVIChpWVmmTBIDluOi3 a12JUByd4y1pSyBCDBz1dEIEmw0one2wTP+20IFBhzt70lvRJ28IU80rUZEXNGLnmFdN kF0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684132967; x=1686724967; h=in-reply-to:from:references:to:content-language:subject:user-agent :mime-version:date:message-id:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=kuhq72APZ5V6gYMZ2vMrOOKLitv4gPNuJ92v7dJN2vY=; b=QST8xgtmiVMqYKhgTo6pMcqaxpniDGywM/Hwz47VgCiGlpbR8/2Hjc62og2wGjwwcK T1Y9Hhf5JEQgTnE52LGhjMpbpy09K/le2UvCeK/nuYFwjJCCQaPc6GKLwaY3AdqXYLI4 oG+rU8jwuXOFxH+3PsdKwKND7WLABDuxtr5rweLsAgqb6TMiR32X6gF8Z8rjupqVZpcB PB/z9fXAXxry+Pku/BFAPyCEjSDTqfqM5fYUGS8DVaSSjp10cYhvKcdB1qrv5COc/UV9 YS7IPpPlTdipEVIrObQZzBpovtdxSxHz4/jO9K+yoDAr76TLB6ACXz1Nojiq4ArVmjIY 76cg== X-Gm-Message-State: AC+VfDwdCmGEZ0Imh5vntenL/sz31fYmKXxbJhZ2eWSArkM8LQNlfwod ZZZdqrBZx+5c6aWLSg0M0MRxTtl5Fww= X-Google-Smtp-Source: ACHHUZ6o/hIN0d0qpvNtrofJypJFPCKqY4LNr1PzfdeFVmcUg7LqdQFMiSrj88jQUP53Hqv9ofr70w== X-Received: by 2002:a0d:e212:0:b0:559:f16f:5c68 with SMTP id l18-20020a0de212000000b00559f16f5c68mr27263066ywe.4.1684132967264; Sun, 14 May 2023 23:42:47 -0700 (PDT) Received: from ?IPV6:2600:1700:bd2c:b810:80f6:4741:9863:ef90? ([2600:1700:bd2c:b810:80f6:4741:9863:ef90]) by smtp.googlemail.com with ESMTPSA id g84-20020a0ddd57000000b00559d9989490sm7543086ywe.41.2023.05.14.23.42.46 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 14 May 2023 23:42:47 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------hCe4pIZN2KI7jILkmBJNs38b" Message-ID: <8a13ca66-0a65-2a3c-f1e3-8736dd30dfe1@gmail.com> Date: Mon, 15 May 2023 01:42:46 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: how do I capture conflicting rows Content-Language: en-US To: pgsql-admin@lists.postgresql.org References: <34308ba9-6033-6e57-f44e-500b2ca9cad5@gmail.com> From: Ron In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------hCe4pIZN2KI7jILkmBJNs38b Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Maybe you can get something for nothing, but I'm dubious; you're going to have to pay a price /somewhere/. On 5/15/23 01:25, Nikhil Ingale wrote: > Thing is there is a list of tables (350+ tables) on which I'm running the > insert query i.e., INSERT INTO table ON CONFLICT DO NOTHING to continue > inserting the records by ignoring the conflicting rows. But, at the same > time I would like to capture the conflicting rows or every single > conflicting column (not just the PK's) and their values for every single > table. > > INSERT INTO TABLE ON CONFLICT DO NOTHING don't even report us on the > conflicting rows. How do I identify what the conflicting rows are by > continuing the inserts to happen even if there are any conflicts. I mean > my insert command shouldn't fail on conflicts but at the same time > conflicts should be reported to the user. > > Regards, > Nik > > On Mon, May 15, 2023 at 11:39 AM Ron wrote: > > On 5/15/23 00:32, Nikhil Ingale wrote: > > Hi All, > > > > The following query inserts the rows by ignoring the rows that has > conflicts. > > > > INSERT INTO test (id,name,age,branch) SELECT * FROM student ON > CONFLICT DO > > NOTHING; > > > > How do I capture the conflicting records to a file while > non conflicting > > records are inserted to the table? > > On conflict insert the PK into a separate table, along with a timestamp > column populated by clock_timestamp().  (That way you can export and > delete > sets of records while it's being written to. > > -- > Born in Arizona, moved to Babylonia. > > -- Born in Arizona, moved to Babylonia. --------------hCe4pIZN2KI7jILkmBJNs38b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Maybe you can get something for nothing, but I'm dubious; you're going to have to pay a price somewhere.

On 5/15/23 01:25, Nikhil Ingale wrote:
Thing is there is a list of tables (350+ tables) on which I'm running the insert query i.e., INSERT INTO table ON CONFLICT DO NOTHING to continue inserting the records by ignoring the conflicting rows. But, at the same time I would like to capture the conflicting rows or every single conflicting column (not just the PK's) and their values for every single table.

INSERT INTO TABLE ON CONFLICT DO NOTHING don't even report us on the conflicting rows. How do I identify what the conflicting rows are by continuing the inserts to happen even if there are any conflicts. I mean my insert command shouldn't fail on conflicts but at the same time conflicts should be reported to the user.

Regards,
Nik

On Mon, May 15, 2023 at 11:39 AM Ron <ronljohnsonjr@gmail.com> wrote:
On 5/15/23 00:32, Nikhil Ingale wrote:
> Hi All,
>
> The following query inserts the rows by ignoring the rows that has conflicts.
>
> INSERT INTO test (id,name,age,branch) SELECT * FROM student ON CONFLICT DO
> NOTHING;
>
> How do I capture the conflicting records to a file while non conflicting
> records are inserted to the table?

On conflict insert the PK into a separate table, along with a timestamp
column populated by clock_timestamp().  (That way you can export and delete
sets of records while it's being written to.

--
Born in Arizona, moved to Babylonia.



--
Born in Arizona, moved to Babylonia.
--------------hCe4pIZN2KI7jILkmBJNs38b--