Re: COPY enhancements

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

Greg Smith wrote:
> On Fri, 11 Sep 2009, Emmanuel Cecchet wrote:
>
>> 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.
>
> Allowing the extra column case is easy: everwhere in copy.c you find
> the error message "extra data after last expected column", just ignore
> the overflow fields rather than rejecting the line just based on
> that. And the default information I mentioned you might want to
> substitute for missing columns is already being collected by the code
> block with the comment "Get default info if needed".
If I understand it well, you expect the garbage to be after the last
column. But what if the extra or missing column is somewhere upfront or
in the middle? Sometimes you might have a type conflict problem that
will help you detect the problem, sometimes you will just insert
garbage. This might call for another mechanism that would log the lines
that are automatically 'adjusted' to be able to rollback any mistake
that might happen during this automated process.

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 Emmanuel Cecchet 2009-09-14 18:51:51 Re: generic copy options
Previous Message Andrew Chernow 2009-09-14 18:34:55 Re: new version of PQconnectdb was:(Re: [HACKERS] Determining client_encoding from client locale)