Horton

Re: VLDB Features

Hannu Krosing <hannu@skype.net>

View thread
From: Hannu Krosing <hannu@skype.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Josh Berkus <josh@agliodbs.com>, Neil Conway <neilc@samurai.com>, pgsql-hackers@postgresql.org, Simon Riggs <simon@2ndquadrant.com>
Date: 2007-12-15T11:10:30Z
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 →

  1. doc: Fix COPY ON_ERROR option syntax synopsis.

  2. Disallow specifying ON_ERROR option without value.

  3. Rename COPY option from SAVE_ERROR_TO to ON_ERROR

  4. Fix spelling in notice

  5. Add new COPY option SAVE_ERROR_TO

Ühel kenal päeval, L, 2007-12-15 kell 01:12, kirjutas Tom Lane:
> 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.

But can't we _define_ such a subset, where we can do a transactionless
load ?

I don't think that most DW/VLDB schemas fire complex triggers or custom
data-modifying functions inside CHECK's.

Then we could just run the remaining simple CHECK constraints ourselves
and not abort on non-check, but just log the rows ?

The COPY ... WITH ERRORS TO ... would essentially become a big
conditional RULE through which the incoming data is processed.

------------------
Hannu