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
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 |