Re: to_timestamp() changes in 8.4 release notes - Mailing list pgsql-hackers

From Brendan Jurd
Subject Re: to_timestamp() changes in 8.4 release notes
Date
Msg-id 37ed240d0904190825m3ae07b9bq8c0469a0f82579c0@mail.gmail.com
Whole thread Raw
In response to Re: to_timestamp() changes in 8.4 release notes  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: to_timestamp() changes in 8.4 release notes  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Apr 20, 2009 at 1:06 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Well, it does seem to have some visible effect --- in 8.3 I see
>
...
> ie, failure to match means the field is silently ignored.  In HEAD,
>
...
> ie, failure to match means you get an error.
>
> I guess though your point is that this is part of the general tightening
> of to_timestamp()'s error checking, and doesn't need a separate entry?
>

You guess correctly =)

There might be some value in changing the wording of that paragraph
about the "general tightening" to emphasise that queries which
previously succeeded (with some parts being misinterpreted or silently
disregarded) will now throw an error.  It is entirely possible that
these changes will break existing queries, although I would like to
hope that there aren't too many people out there relying on the quirky
misbehaviours of to_timestamp().

To this item:
 Cause to_date() and to_timestamp() to more consistently report
errors for invalid input (Brendan Jurd)

We could add a line like:
 Some invalid inputs which were silently ignored or misread in 8.3
and earlier, will now cause an ERROR to be raised.

Cheers,
BJ


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: to_timestamp() changes in 8.4 release notes
Next
From: Tom Lane
Date:
Subject: Re: planner crash/assert hit in 8.4B1