Re: Ragged CSV import

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Ragged CSV import
Date: 2009-09-10 13:58:54
Message-ID: 603c8f070909100658j723c030crce65ffbe9ea958fe@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Sep 10, 2009 at 9:56 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Dimitri Fontaine <dfontaine(at)hi-media(dot)com> writes:
>> Last time we opened this can of worms here's what it lead us to:
>>   http://archives.postgresql.org/pgsql-hackers/2008-04/msg00222.php
>
> Right, that's the discussion I was remembering.
>
>> As already said by Andrew on IRC, though, this goes nowhere to help him
>> address his direct concern, COPY would still choke on input lines that
>> are containing too few or too many columns...
>
> An easy fix for that is to allow this form of COPY to return text[]
> instead of a fixed number of text columns.

Hmm... in fact, what if we just implemented COPY returning text[] for
a first cut, and forget making it act like a table source for now.
Then you could COPY to a temp table (with a text[] column) and select
from there. There's really two separate features here: COPY producing
text[] rather than a record type, and COPY being embeddable in some
larger query.

...Robert

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2009-09-10 14:00:52 Re: pgbench hard coded constants
Previous Message Robert Haas 2009-09-10 13:56:29 Re: Ragged CSV import