From: | "Andrew Dunstan" <andrew(at)dunslane(dot)net> |
---|---|
To: | <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: Updated COPY CSV patch |
Date: | 2004-04-14 09:27:57 |
Message-ID: | 2974.24.211.141.25.1081934877.squirrel@www.dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2004-04-14 09:37:23 | Re: Updated COPY CSV patch |
Previous Message | Karel Zak | 2004-04-14 08:05:27 | Re: Updated COPY CSV patch |