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
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 |