On Mon, Apr 20, 2009 at 1:51 AM, Tom Lane wrote:
> Brendan Jurd writes:
>> There might be some value in changing the wording of that paragraph
>> about the "general tightening"
...
>
> OK, done. I wrote
>
> Previous versions would often ignore or silently misread input
> that did n
Brendan Jurd writes:
> On Mon, Apr 20, 2009 at 1:06 AM, Tom Lane wrote:
>> 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 word
On Mon, Apr 20, 2009 at 1:06 AM, Tom Lane 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
Brendan Jurd writes:
> I noticed the following item under "Observe the following
> incompatibilities" in the 8.4 release notes (E.1.2.4.1.)
> * Require to_timestamp() input to match meridian (AM/PM) and era
> (BC/AD) format designations with respect to presence of periods
> (Brendan Jurd)
>
Hi guys,
I noticed the following item under "Observe the following
incompatibilities" in the 8.4 release notes (E.1.2.4.1.)
* Require to_timestamp() input to match meridian (AM/PM) and era
(BC/AD) format designations with respect to presence of periods
(Brendan Jurd)
For example, input val
