Tsirkin Evgeny wrote:
> > Uh, you just ask and we discuss it on the list.
> >
> > Are you using INSERTs from pg_dump? I assume so because COPY uses a
> > single transaction per command. Right now with pg_dump -d I see:
> >
> > --
> > -- Data for Name: has_oids; Type: TABLE DATA; Schema: public; Owner:
> > postgres
> > --
> >
> > INSERT INTO has_oids VALUES (1);
> > INSERT INTO has_oids VALUES (1);
> > INSERT INTO has_oids VALUES (1);
> > INSERT INTO has_oids VALUES (1);
> >
> > Seems that should be inside a BEGIN/COMMIT for performance reasons, and
> > to have the same behavior as COPY (fail if any row fails). Commands?
> >
> > As far as skipping on errors, I am unsure on that one, and if we put the
> > INSERTs in a transaction, we will have no way of rolling back only the
> > few inserts that fail.
> >
> That is right but there are sutuation when you prefer at least some
> data to be inserted and not all changes to be ralled back because
> of errors.
Added to TODO:
* Have pg_dump use multi-statement transactions for INSERT dumps
For simple performance reasons, it would be good. I am not sure about
allowing errors to continue loading. Anyone else?
--
Bruce Momjian | http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
