From: | Dave Cramer <pg(at)fastcrypt(dot)com> |
---|---|
To: | Quartz <quartz12h(at)yahoo(dot)com> |
Cc: | pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: JDBC gripe list |
Date: | 2011-03-29 21:16:25 |
Message-ID: | AANLkTikZHVSvtvSqnDP3om7vNHc4Y3wE_WeQJg9z4JVv@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
>
> For those who believe the driver is fine when breaking the batch after the
> 1st error, then in my example of 5 inserts with pk id=1 to 5 (with id 2 and
> 4 already present) the table won't contain at least the id=1 (which didn't
> fail).
>
> The postgres driver is partly at fault, but the server is too, for making a
> transaction whene there is none. Try to get any of the 2 sides to work on it
> and they just throw the problem the other way:
> "[server guys]: oh its a driver issue then!..."
> "[driver guys]: oh, its a server issue then!..."
> Nothing gets done, and we are stuck.
>
>
Well in the postgresql world every statement is a transaction. That being
said the concept of batch processing in postgres is that it would be done
in a transaction otherwise what is the point ? If you agree with that then
in the postgres world it would be natural for all of it to fail. At least
thats how I would expect postgres to act.
Dave
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2011-03-29 21:18:34 | Re: JDBC gripe list |
Previous Message | John R Pierce | 2011-03-29 21:05:43 | Re: JDBC gripe list |