Re: Updated COPY CSV patch

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: Updated COPY CSV patch
Date: 2004-04-13 17:37:48
Message-ID: 24460.1081877868@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Well, as I indicated we can deal with this in a subsequent round, I
> think. However, here's an idea. We know (or can easily discover) if
> there is a NOT NULL constraint that can apply to the attribute (or
> domain if it is a domain type). If isnull is set on the read-in value in
> such a case, instead of trying to insert null, and knowing we would
> fail, try to insert the value we actually read (usually ''), even though
> we think we found a null. This will succeed with text fields, and fail
> with, for example, int fields. That strikes me as quite reasonable
> behaviour, although perhaps qualifying for a warning. Or perhaps we
> could enable such behaviour with a flag.

I think this is all a *really really* bad idea. COPY is not supposed
to be an "intuit what the user meant" facility. It is supposed to give
reliable, predictable results, and in particular it *is* supposed to
raise errors if the data is wrong. If you want intuition in
interpreting bogus CSV files then an external data conversion program is
the place to do it.

> Of course, this would be for CSV mode only - standard TEXT mode should
> work as now.

The CSV flag should not produce any fundamental changes in COPY's
behavior, only change the external format it handles. Guessing has
no place here.

regards, tom lane

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2004-04-13 17:45:22 Re: Updated COPY CSV patch
Previous Message Andrew Dunstan 2004-04-13 17:31:13 Re: Updated COPY CSV patch