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

From Andrew Dunstan
Subject Re: Updated COPY CSV patch
Date
Msg-id 2974.24.211.141.25.1081934877.squirrel@www.dunslane.net
Whole thread Raw
In response to Re: Updated COPY CSV patch  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-patches
Bruce Momjian said:
> Andrew Dunstan wrote:
>> I don't believe '' should be special, any more than 'fred' should be.
>> As  it stands now, NULL 'fred' does say that ,, and '"", are empty
>> strings.
>>
>> >Again, I can assist in making these modifications to the patch.
>> >
>> >
>>
>> I appreciate your efforts. But as indicated elsewhere, right now I'm
>> leaning towards reworking this into a client, because the road seems
>> to  be blocked on doing what I regard as necessary in the backend.
>
> I don't agree about moving this to a client.  It is too important for
> that.  Many admin apps and psql need this capability and having it in a
> client just requires everyone to reinvent the wheel.
>
> Let me think over you issues and see what I can come up with.
>
> The patch isn't that big and already does 90% of what we need.  We just
> need ot get that extra 10%.
>

Yeah. Yesterday was a bad day - sorry if I was a bit liverish.

Regrouping ...

The likely failures I see are these:

. on import, a null value is attempted to be inserted into a NOT NULL
field, and
. on export, a column that should have not-null values quoted does not,
confusing the foreign program.

I was trying to be clever and handle these automatically, causing a small
explosion somewhere near Pittsburgh. How about if we are dumb and simply
give finer grained control to the user?

Let's say instead of your per table/file ALL|NONE|STRICT proposal, we have
something like a "FORCE list-of-columns" option. On import, this would
force isnull to be false and on export it would force quoting of non-null
values just for those columns. The problems are not symmetric, but the
solution is the same - make the user decide on a per column basis.

This would have the following happy results:
. what we write would remain unambiguously null-preserving
. you would never need to use (and shouldn't) this option for a
postgresql<->postgresql round trip, assuming the table definitions were
the same.
. even if you wrote a file using this option you could still reimport it
correctly without using the option.
. (fingers crossed) Tom is kept happy.

cheers

andrew



pgsql-patches by date:

Previous
From: Karel Zak
Date:
Subject: Re: Updated COPY CSV patch
Next
From: "Andrew Dunstan"
Date:
Subject: Re: Updated COPY CSV patch