Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6])
	by hub.org (8.9.2/8.9.1) with ESMTP id JAA85437
	for <pgsql-interfaces@postgreSQL.org>;
	Mon, 8 Mar 1999 09:59:28 -0500 (EST)
	(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id JAA06306;
	Mon, 8 Mar 1999 09:58:16 -0500 (EST)
To: "Ken J. Wright" <ken@ori-ind.com>
cc: pgsql-interfaces@postgreSQL.org
Subject: Re: [INTERFACES] copy command & null datetime 
In-reply-to: Your message of Mon, 08 Mar 1999 00:11:39 -0800
	<3.0.32.19990308001137.0088a4a0@ren.cncware.com>
Date: Mon, 08 Mar 1999 09:58:16 -0500
Message-ID: <6304.920905096@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Ken J. Wright" <ken@ori-ind.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