Emmanuel Cecchet <m...@frogthinker.org> writes: > Tom was also suggesting 'refactoring COPY into a series of steps that the > user can control'. What would these steps be? Would that be per row and > allow to discard a bad tuple?
The idea is to have COPY usable from a general SELECT query so that the user control what happens. Think of an SRF returning bytea[] or some variation on the theme. Maybe WITH to the rescue: WITH csv AS ( -- no error here as the destination table is in memory tuple store, -- assuming we have adunstan patch to ignore rows with too few or -- too many columns COPY csv(a, b, c, d) FROM STDIN WITH CSV HEADER --- and said options ) INSERT INTO destination SELECT a, b, f(a + b - d), strange_timestamp_reader(c) FROM csv WHERE validity_check_passes(a, b, c, d); That offers complete control to the user about the stages that transform the data. In a previous thread some ideas I forgot the details offered to the users some more control, but I don't have the time right now to search in the archives. Regards, -- Dimitri Fontaine PostgreSQL DBA, Architecte -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers