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

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: (view raw, whole thread or download thread mbox)
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

pgsql-patches by date

Next:From: Tom LaneDate: 2004-04-13 17:45:22
Subject: Re: Updated COPY CSV patch
Previous:From: Andrew DunstanDate: 2004-04-13 17:31:13
Subject: Re: Updated COPY CSV patch

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