Re: Different length lines in COPY CSV

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgman(at)candle(dot)pha(dot)pa(dot)us, chriskl(at)familyhealth(dot)com(dot)au, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Different length lines in COPY CSV
Date: 2005-12-12 15:55:55
Message-ID: 439D9D8B.8030100@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:

>"Andrew Dunstan" <andrew(at)dunslane(dot)net> writes:
>
>
>>The COPY code is probably on the edge of maintainability now.
>>Our CSV routines accept a wide variety of imports formats, but a fixed
>>number of columns is required. Maybe we need a pgfoundry project with some
>>general perl CSV munging utilities - this issue comes up often enough.
>>
>>
>
>What's been suggested in the past is some sort of standalone
>file-format-conversion utility, which could deal with this sort of stuff
>without having to also deal with all the backend-internal considerations
>that COPY must handle. So (at least in theory) it'd be simpler and more
>maintainable. That still seems like a good idea to me --- in fact,
>given my druthers I would rather have seen CSV support done in such an
>external program.
>
>
>
>

We debated the reasons at the time, and I am not convinced we were wrong
- huge bulk loads are a lot simpler if you don't have to call some
external program to munge the data first.

From time to time people thank me for things I have contributed to in
PostgreSQL. The two that get the most thanks by far are CSV support and
dollar quoting.

Anyway, that's history now. Where would you want this file conversion
utility? bin? contrib? pgfoundry?

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2005-12-12 15:59:18 Re: psql patch: new host/port
Previous Message Andreas Pflug 2005-12-12 15:55:12 Re: pg_relation_size locking