Re: BUG #16419: wrong parsing BC year in to_date() function
От | Tom Lane |
---|---|
Тема | Re: BUG #16419: wrong parsing BC year in to_date() function |
Дата | |
Msg-id | 888835.1601489514@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #16419: wrong parsing BC year in to_date() function (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: BUG #16419: wrong parsing BC year in to_date() function
|
Список | pgsql-hackers |
Bruce Momjian <bruce@momjian.us> writes: > On Tue, Sep 29, 2020 at 01:26:29PM -0400, Tom Lane wrote: >> Bruce Momjian <bruce@momjian.us> writes: >>> On Fri, Sep 4, 2020 at 12:45:36PM -0700, David G. Johnston wrote: >>>> 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. >> 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? > You are agreeing with what I am suggesting then? Hm, I read your reference to "the release notes" as suggesting that we should change it only in a major release, ie HEAD only (and it looks like David read it the same). If you meant minor release notes, then we're on the same page. regards, tom lane
В списке pgsql-hackers по дате отправления: