| From: | Vitalii Tymchyshyn <vit(at)tym(dot)im> |
|---|---|
| To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com> |
| Cc: | John R Pierce <pierce(at)hogranch(dot)com>, "pgsql-jdbc(at)postgresql(dot)org" <pgsql-jdbc(at)postgresql(dot)org> |
| Subject: | Re: JDBC behaviour |
| Date: | 2016-02-20 16:01:04 |
| Message-ID: | CABWW-d3Mu=vto2ML22Q+iQe-znNkQLyyew_FJmZn086oBLiqKA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-hackers pgsql-jdbc |
Well, it OT here and belongs to -hackers, but as for me main use case here
is ETL or ELT process getting a lot of unvalidated external data.
And a good option to solve this problem is not to change transaction
semantics or slow down processing by adding tons of savepoints, but add "on
error" clause to insert/copy statement.
This clause should allow to save records that can't fit into destination
table because of type, check of referential constaints into error table.
Oracle has similar functionality and we are using it in our project. No
error is generated - no transaction rollback, batch abort or similar.
As for me it would cover 90% of use cases and would be really usefull. The
one problem I can see is with inserting into partition parent.
Best regards, Vitalii Tymchyshyn
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bill Moran | 2016-02-20 16:16:25 | Re: JDBC behaviour |
| Previous Message | David G. Johnston | 2016-02-20 15:34:14 | Re: JDBC behaviour |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bill Moran | 2016-02-20 16:16:25 | Re: JDBC behaviour |
| Previous Message | David G. Johnston | 2016-02-20 15:34:14 | Re: JDBC behaviour |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bill Moran | 2016-02-20 16:16:25 | Re: JDBC behaviour |
| Previous Message | David G. Johnston | 2016-02-20 15:34:14 | Re: JDBC behaviour |