Thank you Tom for looking at this.
I would be pleased to help on testing the fix when available.
My plan is to store Informix INTERVALs (coming from the 4gl applications we
support) into PostgreSQL INTERVALs, and I have a bunch of tests for that...
I believe Informix INTERVALs (and related operators and functions) are not
100% SQL99, but they are close...
Thanks a lot!
Seb
Tom Lane wrote:
Sebastien FLAESCH <s...@4js.com> writes:
I would expect that an INTERVAL SECOND can store more that 59 seconds.
I took a look into the SQL spec and I think that we do indeed have a
spec compliance issue here. SQL99 section 4.7 saith
Within a value of type interval, the first field is constrained
only by the <interval leading field precision> of the associated
<interval qualifier>. Table 8, "Valid values for fields in INTERVAL
values", specifies the constraints on subsequent field values.
[ Table 8 says about what you'd expect, eg 0..23 for HOUR ]
Values in interval fields other than SECOND are integers and have
precision 2 when not the first field. SECOND, however, can be
defined to have an <interval fractional seconds precision> that
indicates the number of decimal digits maintained following the
decimal point in the seconds value. When not the first field,
SECOND has a precision of 2 places before the decimal point.
So in other words, "999 seconds" is a valid value for a field of type
INTERVAL SECOND, *and should come out the same way*, not as "00:16:39",
and certainly not as "00:00:39".
It might be a relatively easy fix to not truncate the input value
incorrectly. I haven't looked, but I think we should look now, because
8.4 has already changed the behavior in this area and it would be good
not to change it twice. The focus of the 8.4 work was to make sure that
we would correctly interpret the values of spec-compliant interval
literals, but this example shows we are not there yet.
We are fairly far away from being able to make it print out as the spec
would suggest, because interval_out simply doesn't have access to the
information that the field is constrained to be INTERVAL SECOND rather
than some other kind of interval. We also have got no concept at all of
<interval leading field precision>, only of <interval fractional seconds
precision>, so constraining the leading field to only a certain number
of integral digits isn't possible either. I don't foresee anything
getting done about either of those points for 8.4.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
