|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> 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
|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|
|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|