Received: from golem.jpl.nasa.gov (IDENT:postfix@dialin-111.jpl.nasa.gov
	[128.149.231.111])
	by hub.org (8.10.1/8.10.1) with ESMTP id e6H6I2085656
	for <pgsql-sql@postgresql.org>; Mon, 17 Jul 2000 02:18:02 -0400 (EDT)
Received: from alumni.caltech.edu (localhost.localdomain [127.0.0.1])
	by golem.jpl.nasa.gov (Postfix) with ESMTP
	id 1E9166F4F; Mon, 17 Jul 2000 06:23:22 +0000 (UTC)
Message-ID: <3972A65A.FBC3E35D@alumni.caltech.edu>
Date: Mon, 17 Jul 2000 06:23:22 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
Organization: Yes
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.14-15mdksmp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Philip Warner <pjw@rhyme.com.au>, Carolyn Lu Wong <carolyn@kss.net.au>,
	"pgsql-sql@postgresql.org" <pgsql-sql@postgresql.org>
Subject: Re: SQL question
References: <3.0.5.32.20000717121856.022cd100@mail.rhyme.com.au>
	<3.0.5.32.20000717141152.022dd100@mail.rhyme.com.au>
	<28464.963812928@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Archive-Number: 200007/166

> The immediate cause of this gripe was discussed just a day or so ago
> on one or another of the pgsql lists.  The timestamp-to-date conversion
> routine has this weird idea that it should kick out an error instead
> of returning NULL when presented with a NULL timestamp.  That's a bug
> IMHO, and I've already changed the code in current sources.

That's not a bug, that was a feature, sort of. At least when I coded it,
Postgres *refused* to call any routine with NULL input, assuming that
NULL would be returned. A clever short-circuit, and the elog(ERROR) in
the conversion routine was just a safety net. Because it was also the
case that any routine returning a NULL pointer crashed the backend.

Now that those things aren't true, we are rewriting history to say that
they were bugs all along, eh? ;)

                      - Thomas