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

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: BUG #16419: wrong parsing BC year in to_date() function
Дата
Msg-id CAKFQuwZV0UxbyYTxuJhf1j1X=3HG5QA6qtEp+C+=LzOFtNEt3A@mail.gmail.com
обсуждение исходный текст
Ответ на 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
Re: BUG #16419: wrong parsing BC year in to_date() function
Список pgsql-hackers
On Thu, Sep 3, 2020 at 6:21 PM Bruce Momjian <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.

David J.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Questionable ping logic in LogicalRepApplyLoop
Следующее
От: Juan José Santamaría Flecha
Дата:
Сообщение: Re: A micro-optimisation for walkdir()