Michael Glaesemann <[EMAIL PROTECTED]> writes:
> I've started working on this change, and one difference has shown up
> immediately in the regression tests. v8.0.3 currently returns:
>SELECT INTERVAL '10 years -11 month -12 days +13:14' AS "9 years...";
>9 years...
>-
Michael Glaesemann <[EMAIL PROTECTED]> writes:
> On Jun 1, 2005, at 1:42 PM, Michael Glaesemann wrote:
>> -- v8.0.3
>> test=# select '25 hours'::interval;
>> interval
>>
>> 1 day 01:00:00
>> (1 row)
>>
>> -- new interval code
>> test=# select '25 hours'::interval;
>> interval
>> -
On Jun 1, 2005, at 1:42 PM, Michael Glaesemann wrote:
-- v8.0.3
test=# select '25 hours'::interval;
interval
1 day 01:00:00
(1 row)
-- new interval code
test=# select '25 hours'::interval;
interval
--
25:00:00
(1 row)
I'll be digging into the spec later and post w
Michael Glaesemann <[EMAIL PROTECTED]> writes:
> On May 31, 2005, at 12:48 AM, Tom Lane wrote:
>> Actually, practically all of the Postgres code assumes int is at least
>> 32 bits. Feel free to change pg_tm's field to be declared int32
>> instead
>> of just int if that bothers you, but it is rea
On May 31, 2005, at 1:40 AM, Tom Lane wrote:
Josh Berkus writes:
Unfortunately, it appears that tri-partitioning INTERVAL ( year/
month ;
week/day ; hour/minute/second ) is a violation of the SQL spec
which has only
the two partitions ( year/month ; week/day/hour/minute/second ).
I
On May 31, 2005, at 12:48 AM, Tom Lane wrote:
Michael Glaesemann <[EMAIL PROTECTED]> writes:
tm_mday is an int value, which is only guaranteed to be 2
bytes (though it may be larger), if I understand correctly.
Actually, practically all of the Postgres code assumes int is at least
32
Josh Berkus writes:
> Unfortunately, it appears that tri-partitioning INTERVAL ( year/month ;
> week/day ; hour/minute/second ) is a violation of the SQL spec which has only
> the two partitions ( year/month ; week/day/hour/minute/second ).
I think it's an extension of the spec, not a violation.
Michael,
> One advantage of this is that it would allow '1 day' to have a
> different meaning that '24 hours', which would be meaningful when
> crossing daylight saving time changes. For example, PostgreSQL
> returns the following results:
I've been stumping for this for years. See my arguments
Michael Glaesemann <[EMAIL PROTECTED]> writes:
> When the string is read by DecodeInterval, the "days" component is
> assigned to tm_mday. It seems relatively straightforward to use this
> input to provide the interval->day value. However, I'm wondering what
> range of days this the interval-
There has been discussion in the past of including number of days as
part of the Interval structure in addition to the current months and
time components. Here are some mailing list threads where the topic
has arisen.
[Re: [GENERAL] '1 year' = '360 days' ](http://
archives.postgresql.o
10 matches
Mail list logo
