From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: BUG #16419: wrong parsing BC year in to_date() function |
Date: | 2020-09-29 18:18:58 |
Message-ID: | 712970.1601403538@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
I wrote:
> I think this is nuts. The current behavior is obviously broken;
> we should just treat it as a bug and fix it, including back-patching.
> I do not think there is a compatibility problem of any significance.
> Who out there is going to have an application that is relying on the
> ability to insert BC dates in this way?
Concretely, I propose the attached. This adjusts Dar Alathar-Yemen's
patch (it didn't do the right thing IMO for the combination of bc
and year < 0) and adds test cases and docs.
Oracle would have us throw an error for year zero, but our historical
behavior has been to read it as 1 BC. That's not so obviously wrong
that I'd want to change it in the back branches. Maybe it could be
done as a follow-up change in HEAD.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
fix-to-date-for-negative-years.patch | text/x-diff | 4.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Nagaraj Raj | 2020-09-29 18:22:50 | Re: recovery.conf' is not creating in pg_basebackup with version 13 |
Previous Message | Nagaraj Raj | 2020-09-29 18:18:25 | Re: table partition with inheritance having current_timestamp issue if we miss range table |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2020-09-29 18:33:42 | Re: BLOB / CLOB support in PostgreSQL |
Previous Message | Andrey M. Borodin | 2020-09-29 18:04:18 | Re: Yet another fast GiST build |