Re: Ragged CSV import - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Ragged CSV import
Date
Msg-id 603c8f070909091743s9b44d80sc3ced348de688378@mail.gmail.com
Whole thread Raw
In response to Re: Ragged CSV import  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Ragged CSV import
List pgsql-hackers
On Wed, Sep 9, 2009 at 7:41 PM, Andrew Dunstan<andrew@dunslane.net> wrote:
>
>
> Robert Haas wrote:
>>
>> I agree that ignoring extra columns is a bad idea, but I don't even
>> like the idea of ignoring missing columns.  It doesn't seem like a
>> good idea to take a spreadsheet and feed it into COPY without doing
>> any validation anyway, and this is the kind of thing that is trivial
>> to clean up with a thin layer of Perl or your scripting language of
>> choice.
>>
>>
>
> If it's an optional feature then I don't see why there is a problem. What
> skin is it off anyone else's nose but those whose choose this behaviour?

I have to admit I'm usually an advocate of that way of thinking, so
maybe I am all wet.  I suppose it comes down to whether you think this
particular feature is something with broad applicability, or whether
there are 100 other equally plausible features.

I wonder whether it would be appropriate to do something like
implement a method by which copy could return text[] and then one
could write wrappers around that functionality to do this as well as
other things.  For example, suppose you wanted to have rows of the
form:

A,B,C,X1,Y1,X2,Y2,X3,Y3

...which gets transformed into an insert of (A,B,C) into a main table
and (A,X1,Y1), (A,X2,Y2), (A,X3,Y3) into a side table.  (I have actual
knowledge of a widely-deployed system produced by a large company that
outputs data in a format similar to this, though the actual format is
considerably more complex.)

...Robert


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: RfD: more powerful "any" types
Next
From: Robert Haas
Date:
Subject: Re: Bug in aggregates in windowing context