Re: Updated COPY CSV patch

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

In response to

Responses

Browse pgsql-patches by date

  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