Skip site navigation (1) Skip section navigation (2)

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-14 09:27:57
Message-ID: (view raw, whole thread or download thread mbox)
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.



In response to

pgsql-patches by date

Next:From: Andrew DunstanDate: 2004-04-14 09:37:23
Subject: Re: Updated COPY CSV patch
Previous:From: Karel ZakDate: 2004-04-14 08:05:27
Subject: Re: Updated COPY CSV patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group