| From: | Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Philip Warner <pjw(at)rhyme(dot)com(dot)au>, Carolyn Lu Wong <carolyn(at)kss(dot)net(dot)au>, "pgsql-sql(at)postgresql(dot)org" <pgsql-sql(at)postgresql(dot)org> |
| Subject: | Re: SQL question |
| Date: | 2000-07-17 06:23:22 |
| Message-ID: | 3972A65A.FBC3E35D@alumni.caltech.edu |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-sql |
> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2000-07-17 06:26:31 | Re: SQL question |
| Previous Message | Tom Lane | 2000-07-17 05:48:48 | Re: SQL question |