Re: BUG #16419: wrong parsing BC year in to_date() function

Peter Eisentraut <peter.eisentraut@2ndquadrant.com>

From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: "David G. Johnston" <david.g.johnston@gmail.com>, Bruce Momjian <bruce@momjian.us>
Cc: Laurenz Albe <laurenz.albe@cybertec.at>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-09-04T21:05:28Z
Lists: pgsql-bugs, pgsql-hackers

Attachments

On 2020-09-04 21:45, David G. Johnston wrote:
> On Thu, Sep 3, 2020 at 6:21 PM Bruce Momjian <bruce@momjian.us 
> <mailto:bruce@momjian.us>> wrote:
> 
>     On Wed, Jul 15, 2020 at 09:26:53AM -0700, David G. Johnston wrote:
> 
>      > Whether to actually change the behavior of to_date is up for
>     debate though I
>      > would presume it would not be back-patched.
> 
>     OK, so, looking at this thread, we have to_date() treating -1 as -2 BC,
>     make_date() treating -1 as 1 BC, and we have Oracle, which to_date() is
>     supposed to match, making -1 as 1 BC.
> 
>     Because we already have the to_date/make_date inconsistency, and the -1
>     to -2 BC mapping is confusing, and doesn't match Oracle, I think the
>     clean solution is to change PG 14 to treat -1 as 1 BC, and document the
>     incompatibility in the release notes.
> 
> 
> I agree that someone else should write another patch to fix the behavior 
> for v14.  Still suggest committing the proposed patch to master and all 
> supported versions to document the existing behavior correctly.  The fix 
> patch can work from that.

Adding support for negative years in make_timestamp seems pretty 
straightforward; see attached patch.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Commits

  1. Fix handling of BC years in to_date/to_timestamp.

  2. Fix make_timestamp[tz] to accept negative years as meaning BC.

  3. doc: PG 13 relnotes, update TOAST item to mention decompression