Re: VLDB Features

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>

To: Josh Berkus <josh@agliodbs.com>

Cc: Neil Conway <neilc@samurai.com>, Hannu Krosing <hannu@skype.net>, pgsql-hackers@postgresql.org, Simon Riggs <simon@2ndquadrant.com>

Date: 2007-12-15T06:12:58Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

doc: Fix COPY ON_ERROR option syntax synopsis.
- f6f8ac8e75c9 17.0 landed
Disallow specifying ON_ERROR option without value.
- a6d0fa5ef840 17.0 landed
Rename COPY option from SAVE_ERROR_TO to ON_ERROR
- b725b7eec431 17.0 landed
Fix spelling in notice
- 58fbbc9d683c 17.0 landed
Add new COPY option SAVE_ERROR_TO
- 9e2d8701194f 17.0 landed

Josh Berkus <josh@agliodbs.com> writes:
> There's no way we can do a transactionless load, then?  I'm thinking of the 
> load-into-new-partition which is a single pass/fail operation.  Would 
> ignoring individual row errors in for this case still cause these kinds of 
> problems?

Given that COPY fires triggers and runs CHECK constraints, there is no
part of the system that cannot be exercised during COPY.  So I think
supposing that we can just deal with some simplified subset of reality
is mere folly.

			regards, tom lane