Re: COPY issue(gsoc project)

Hi Longlong,

> > i think this is a better idea.
> from *NikhilS *
> http://archives.postgresql.org/pgsql-hackers/2007-12/msg00584.php
> But instead of using a per insert or a batch insert substraction, I am
> thinking that we can start off a subtraction and continue it till we
> encounter a failure. The moment an error is encountered, since we have the
> offending (already in heap) tuple around, we can call a simple_heap_delete
> on the same and commit (instead of aborting) this subtransaction after doing
> some minor cleanup. This current input data row can also be logged into a
> bad file. Recall that we need to only handle those errors in which the
> simple_heap_insert is successful, but the index insertion or the after row
> insert trigger causes an error. The rest of the load then can go ahead with
> the start of a new subtransaction.
> the simplest thing are often the best.
> i think it's hard to implement or some other deficiency since you want
> subtransaction or every "n" rows.
>

Yeah simpler things are often the best, but as folks are mentioning, we need
a carefully thought out approach here. The reply from Tom to my posting
there raises issues which need to be taken care of. Although I still think
that if we carry out *sanity* checks before starting the load about presence
of triggers, constrainsts, fkey constraints etc, if others do not have any
issues with the approach, the simple_heap_delete idea should work in some
cases. Although the term I used "after some minor cleanup" might need some
thought too now that I think more of it..

Also if Fkey checks or complex triggers are around, maybe we can fall back
to a subtransaction per row insert too as a worse case measure..

Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com