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
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 |