Andrew Gierth wrote:
>>>>>> "James" == James Pye <li...@jwp.name> writes:
>
> James> Is the new date_recv() constraint actually correct?
>
> No, it's not:
Oops, you're right. The check is indeed confusing julian day numbers,
with epoch at 23th of Nov 4714 BC, with postgres-reckoning day numbers,
with epoch at 1th of Jan 2000. Thanks, will fix.
BTW, I just noticed that to_date() doesn't respect those limits either:
postgres=# create table x (a date);
CREATE TABLE
postgres=# insert into x values (to_date('-4713 11 23', 'YYYY MM DD'));
INSERT 0 1
postgres=# select * from x;
a
---------------
4714-11-23 BC
(1 row)
postgres=# copy x to '/tmp/tst.dmp'; -- text mode
COPY 1
postgres=# copy x from '/tmp/tst.dmp';
ERROR: date out of range: "4714-11-23 BC"
CONTEXT: COPY x, line 1, column a: "4714-11-23 BC"
The date arithmetic operators + and - also allow you to create such
dates. I also note that they don't check for overflow.
I'm thinking that we should fix all that by adding range checks to all
those functions (or maybe just in date2j() and the operators).
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
