Re: Updated COPY CSV patch - Mailing list pgsql-patches

From Andrew Dunstan
Subject Re: Updated COPY CSV patch
Date
Msg-id 407C0904.9040706@dunslane.net
Whole thread Raw
In response to Re: Updated COPY CSV patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Updated COPY CSV patch  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
Tom Lane wrote:

>Andrew Dunstan <andrew@dunslane.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

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: Updated COPY CSV patch
Next
From: Andrew Dunstan
Date:
Subject: Re: Updated COPY CSV patch