Re: Bug in to_timestamp().

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Steve Crawford <scrawford(at)pinpointresearch(dot)com>
Cc: Alex Ignatov <a(dot)ignatov(at)postgrespro(dot)ru>, Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, "Tom Lane *EXTERN*" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, amul sul <sul_amul(at)yahoo(dot)co(dot)in>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Bug in to_timestamp().
Date: 2016-06-24 20:33:59
Message-ID: CA+Tgmoa65k+PQNNAu717DdjaA9-uGMWt=ov0NUWmUXggZRRY3A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jun 24, 2016 at 12:26 PM, Steve Crawford
<scrawford(at)pinpointresearch(dot)com> wrote:
> My observation has been that the PostgreSQL development group aims for
> correctness and the elimination of surprising results. This was part of the
> reason to eliminate a number of automatic casts to dates in earlier
> versions.
>
> To me, 2016-02-30 is an invalid date that should generate an error.
> Automatically and silently changing it to be 2016-03-01 strikes me as a
> behavior I'd expect from a certain other open-source database, not
> PostgreSQL.

I don't particularly disagree with that, but on the other hand, as
mentioned earlier, to_timestamp() is here for Oracle compatibility,
and if it doesn't do what Oracle's function does, then (1) it's not
useful for people migrating from Oracle and (2) we're making up the
behavior out of whole cloth. I think things that we invent ourselves
should reject stuff like this, but in a compatibility function we
might want to, say, have compatibility.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2016-06-24 21:09:58 Re: tuplesort.c's copytup_index() is dead code
Previous Message Robert Haas 2016-06-24 19:16:58 Re: Postgres_fdw join pushdown - wrong results with whole-row reference