Re: COPY enhancements

From: Emmanuel Cecchet <manu(at)asterdata(dot)com>
To: Greg Smith <gsmith(at)gregsmith(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Emmanuel Cecchet <manu(at)asterdata(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: COPY enhancements
Date: 2009-09-11 22:35:46
Message-ID: 4AAAD0C2.2060800@asterdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Smith wrote:
> The full set of new behavior here I'd like to see allows adjusting:
>
> -Accept or reject rows with extra columns?
> -Accept or reject rows that are missing columns at the end?
> --Fill them with the default for the column (if available) or NULL?
> -Save rejected rows?
> --To a single system table?
> --To a user-defined table?
> --To the database logs?
The proposed patch save all rejected rows (with extra or missing
columns) to a user-defined table (that can be created automatically). If
you want to handle these bad rows on the fly, I guess you could have a
trigger on the error table that does the appropriate processing
depending on the data you are processing. In that case, having multiple
error tables allows you to plug different triggers to handle possible
error cases differently. The other option is to process the error table
after COPY to handle the bad rows.
I guess the problem with extra or missing columns is to make sure that
you know exactly which data belongs to which column so that you don't
put data in the wrong columns which is likely to happen if this is fully
automated.

I will try to re-read the thread on your proposal to better understand
how you figure out which rows are missing or extra.

Emmanuel

--
Emmanuel Cecchet
Aster Data Systems
Web: http://www.asterdata.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2009-09-11 22:36:56 Re: COPY enhancements
Previous Message Jeff Davis 2009-09-11 22:13:44 Re: COALESCE and NULLIF semantics