Re: BUG #16419: wrong parsing BC year in to_date() function
От | Peter Eisentraut |
---|---|
Тема | Re: BUG #16419: wrong parsing BC year in to_date() function |
Дата | |
Msg-id | 13c0992c-f15a-a0ca-d839-91d3efd965d9@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: BUG #16419: wrong parsing BC year in to_date() function ("David G. Johnston" <david.g.johnston@gmail.com>) |
Ответы |
Re: BUG #16419: wrong parsing BC year in to_date() function
Re: BUG #16419: wrong parsing BC year in to_date() function |
Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: