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
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
--
25:00:00
(1
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...
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
On May 31, 2005, at 1:40 AM, Tom Lane wrote:
Josh Berkus josh@agliodbs.com 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 ;
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 really quite
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://
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-day
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
Josh Berkus josh@agliodbs.com 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,
10 matches
Mail list logo
