Re: Updated COPY CSV patch

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: pgsql-patches(at)postgresql(dot)org
Subject: Re: Updated COPY CSV patch
Date: 2004-04-13 14:18:53
Message-ID: 407BF6CD.3000005@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Andrew Dunstan wrote:

>Bruce Momjian said:
>
>
>>Second, I found a problem with NULLs. If I do:
>>.
>> test=> create table test (x text, y text);
>> CREATE TABLE
>> test=> insert into test values ('', NULL);
>> INSERT 17221 1
>> test=>
>>
>>then this:
>>
>> test=> copy test to '/tmp/b' with csv;
>>
>>creates:
>>
>> "",
>>
>>and this:
>>
>> test=> copy test to '/tmp/b' with csv NULL 'fred';
>>
>>creates:
>>
>> ,fred
>>
>>Is that logical? A non-null field went from "" to nothing.
>>
>>
>>
>
>One more point about this - we can't force quoting of every non-null
>value, which would remove the "inconsistency" you see here, because
>spreadsheets especially infer information from whether or not a CSV value
>is quoted. In particular, they will not usually treat a quoted numeric
>value as numeric, which would be a very undesirable effect.
>
>
>

Thinking about this some more .... maybe the right rule would be "quote
all non-numeric non-null values". That would fix the odd effect that
Bruce saw, and it would also stop a spreadsheet from interpreting a date
like 2002-03-04 as an arithmetic expression.

Note that we don't care if a value is quoted or not - the only inference
we draw from it is that if it is quoted it can't be null. We don't need
to draw type inferences from it because we know the type we are trying
to import into from the table defn. This fits nicely with the rule about
being liberal with what you accept.

Thoughts?

cheers

andrew

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2004-04-13 14:43:35 Re: Updated COPY CSV patch
Previous Message Bruno Wolff III 2004-04-13 12:38:18 Re: Updated COPY CSV patch