Re: to_timestamp() changes in 8.4 release notes

From: Brendan Jurd <direvus(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: to_timestamp() changes in 8.4 release notes
Date: 2009-04-19 15:25:00
Message-ID: 37ed240d0904190825m3ae07b9bq8c0469a0f82579c0@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Apr 20, 2009 at 1:06 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-04-19 15:26:18 Re: planner crash/assert hit in 8.4B1
Previous Message Tom Lane 2009-04-19 15:06:50 Re: to_timestamp() changes in 8.4 release notes