Re: Re: [PATCH] Integer overflow in timestamp[tz]_part() and date/time boundaries check

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>
Cc: David Steele <david(at)pgmasters(dot)net>, Vitaly Burovoy <vitaly(dot)burovoy(at)gmail(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: [PATCH] Integer overflow in timestamp[tz]_part() and date/time boundaries check
Date: 2016-03-17 00:13:06
Message-ID: 20606.1458173586@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru> writes:
> There is an issue, mentioned in the thread above:

>> postgres=# select
>> postgres-# to_char(date_trunc('week', '4713-01-01 BC'::date),'day')
>> postgres-# ,to_char(date_trunc('week', '4714-12-29 BC'::date),'day')
>> postgres-# ,to_char(date_trunc('week', '4714-12-28 BC'::date),'day');
>> to_char | to_char | to_char
>> -----------+-----------+-----------
>> monday | monday | thursday
>> (1 row)

>> since 4714-12-28 BC and to the past detection when a week is starting
>> is broken (because it is boundary of isoyears -4713 and -4712).

BTW, I think the actual problem is that j2day() figured that coercing
its argument to unsigned int would be sufficient to produce a sane
answer for negative inputs. It isn't. Nobody sees this with inputs
after 4714BC, but when probing in 4714 the code considers the
reference point 4714-01-04, which has a negative Julian date and so
we end up passing a negative date to j2day().

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message James Sewell 2016-03-17 01:07:47 Re: Choosing parallel_degree
Previous Message David G. Johnston 2016-03-17 00:02:40 Re: plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types