On 12 August 2011 23:19, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: >>> Triggers complicate this. I believe it is only safe to group tuples >>> together >>> like this if the table has no triggers. A BEFORE ROW trigger might run a >>> SELECT on the table being copied to, and check if some of the tuples >>> we're >>> about to insert exist. If we run BEFORE ROW triggers for a bunch of >>> tuples >>> first, and only then insert them, none of the trigger invocations will >>> see >>> the other rows as inserted yet. Similarly, if we run AFTER ROW triggers >>> after inserting a bunch of tuples, the trigger for each of the insertions >>> would see all the inserted rows. So at least for now, the patch simply >>> falls >>> back to inserting one row at a time if there are any triggers on the >>> table.
I guess DEFAULT values could also suffer from a similar problem to BEFORE ROW triggers though (in theory a DEFAULT could be based on a function that SELECTs from the table being copied to). Regards, Dean -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
