From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: BUG #16419: wrong parsing BC year in to_date() function |
Date: | 2020-07-15 16:26:53 |
Message-ID: | CAKFQuwb_3yNTTE6cG_YtXFtV=CkQf0uMSMB0oxC1YNrF94pfuA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
On Tue, May 12, 2020 at 8:56 PM Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
wrote:
> On Tue, 2020-05-12 at 18:09 -0700, David G. Johnston wrote:
> > Redirecting to -hackers for visibility. I feel there needs to be
> something done here, even if just documentation (a bullet in the usage
> notes section - and a code comment update for the macro)
> > pointing this out and not changing any behavior.
>
> Since "to_date" is an Oracle compatibility function, here is what Oracle
> 18.4 has to say to that:
>
> SQL> SELECT to_date('0000', 'YYYY') FROM dual;
> SELECT to_date('0000', 'YYYY') FROM dual
> *
> ERROR at line 1:
> ORA-01841: (full) year must be between -4713 and +9999, and not be 0
>
>
Attached is a concrete patch (back-patchable hopefully) documenting the
current reality.
As noted in the patch commit message (commentary really):
make_timestamp not agreeing with make_date on how to handle negative years
should probably just be fixed - but that is for someone else to handle.
Whether to actually change the behavior of to_date is up for debate though
I would presume it would not be back-patched.
David J.
Attachment | Content-Type | Size |
---|---|---|
v1-001-to-date-behavior-in-bc-bug16419.patch | application/octet-stream | 7.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2020-07-16 04:54:58 | BUG #16544: How to identify trigger is called from the node where row is created? |
Previous Message | Arthur Nascimento | 2020-07-15 12:52:37 | Re: BUG #16542: High CPU Usage |
From | Date | Subject | |
---|---|---|---|
Next Message | Konstantin Knizhnik | 2020-07-15 17:10:06 | Re: Postgres is not able to handle more than 4k tables!? |
Previous Message | Andres Freund | 2020-07-15 15:51:37 | Re: Have SIGHUP instead of SIGTERM for config reload in logical replication launcher |