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

Поиск
Список
Период
Сортировка
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 we need to apply the patches to all branches at the same time.
> I am not sure we want to document a behavior we know will change in PG
> 14.

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?

            regards, tom lane



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Dumping/restoring fails on inherited generated column
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BUG #16419: wrong parsing BC year in to_date() function