Re: [INTERFACES] copy command & null datetime

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Ken J(dot) Wright" <ken(at)ori-ind(dot)com>
Cc: pgsql-interfaces(at)postgreSQL(dot)org
Subject: Re: [INTERFACES] copy command & null datetime
Date: 1999-03-08 14:58:16
Message-ID: 6304.920905096@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-interfaces

"Ken J. Wright" <ken(at)ori-ind(dot)com> writes:
> But in the specific case of a datetime column, wouldn't you think a null
> would be reasonable rather than a failed load? After all, a date can't be
> empty, only null.

Well ... if you go down that path, you find yourself trying to remember
which datatypes accept an empty string as meaning NULL and which don't.
I don't much like that idea; NULL is a type-independent concept and
ought to have a type-independent representation.

An example where the behavior would be far from obvious is char(n)
(not varchar, but the fixed-length string type). A zero-length input
wouldn't be a valid value for n>0, so it could be taken to mean NULL.
On the other hand, char(n) has historically accepted inputs of length
< n and blank-padded them, so converting empty input to n spaces would
also be expected behavior.

Of course \N has its own problems in this respect: unless you know about
backslash-escaping rules, it's not obvious that \N is not a legal data
value for a string. But we need an escaping mechanism anyway, in order
to deal with newlines and tabs in text strings, so there has to be some
ugliness of this kind.

regards, tom lane

Browse pgsql-interfaces by date

  From Date Subject
Next Message Tom Lane 1999-03-08 15:47:38 Re: [INTERFACES] Counting updates with libpq
Previous Message Byron Nikolaidis 1999-03-08 14:27:34 Re: [INTERFACES] row count