From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: Updated COPY CSV patch |
Date: | 2004-04-13 15:36:36 |
Message-ID: | 407C0904.9040706@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Tom Lane wrote:
>Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>
>
>>Thinking about this some more .... maybe the right rule would be "quote
>>all non-numeric non-null values".
>>
>>
>
>And how would you define "numeric"?
>
>
At least the following:
int8
int2
int4
float4
float8
numeric
money
and domains based on them.
>I do *not* like putting data-type-specific knowledge into COPY.
>
>
I'm trying to keep this as simple as possible. But we have to be a bit
smart if we want to be able to export nicely. Here's the problem: say
you have a text field that stores something that has numeric form (phone
number, SSN, whatever). You want that exported as text (i.e. quoted).
Otherwise, things like leading zeros will get lost by the importing
program. However, you *must* not quote genuine number values, or they
will not be imported correctly either. So, either we get a little bit
smart about the types we are exporting, or our export is going to be
broken in some cases. We need to be able to use more information than is
contained in the text representation of the value.
I would certainly hope to keep all this confined to the CSV code path,
and not intrude on any existing functionality in any way.
Exporting nicely has a lot more wrinkles than importing nicely, because
predicting the behaviour of the program we might be exporting to is
difficult.
If you can suggest a better way I'm all ears.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2004-04-13 16:27:54 | Re: Updated COPY CSV patch |
Previous Message | Tom Lane | 2004-04-13 14:43:35 | Re: Updated COPY CSV patch |