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
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 |