Re: INSERT ALL with DML ERROR Logging replacement in PostgreSQL

From: Jagmohan Kaintura <jagmohan(at)tecorelabs(dot)com>
To: "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: INSERT ALL with DML ERROR Logging replacement in PostgreSQL
Date: 2022-06-23 06:25:38
Message-ID: CA+cYFtvn9cr3rOzRd7-G+DOrOkndjYFMA1R6HsiGmg7VD-J5fg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi ALl,

Any other thought on this thread.

On Tue, Jun 21, 2022 at 2:24 PM Gilles Darold <gilles(at)darold(dot)net> wrote:

> Le 21/06/2022 à 10:28, Jagmohan Kaintura a écrit :
>
> Hi Gilles,
>
> I was going though this earlier today but didn't compiled it as I read it
> may not be able to capture the errors if we have below type of statement
> and most of our statements are of INSERT .. SELECT statements only.
>
> The form INSERT INTO <tablename> SELECT ... will not have the same
> behavior than in Oracle. It will not stored the successful insert and
> logged the rows in error. This is not supported because it is a single
> transaction for PostgreSQL and everything is rolled back in case of error.
>
> Our all statements are of that form will it be still useful.
>
>
> Right, this was not obvious in your post, but yes if you are using INSERT
> + SELECT this is not possible with the current version of this extension.
> Maybe that could be possible by rewriting internally the query to loop over
> the result of the select and generate an insert per row returned, but with
> performances lost of courses.
>
>
> Best regards,
>
> --
> Gilles Daroldhttp://www.darold.net/
>
>

--
*Best Regards,*
Jagmohan

In response to

Browse pgsql-general by date

  From Date Subject
Next Message houzj.fnst@fujitsu.com 2022-06-23 07:09:11 RE: Support logical replication of DDLs
Previous Message Matthias Apitz 2022-06-23 04:57:30 Re: function currtid2() in SQL and ESQL/C to get the new CTID of a row