Thread: interval( 'seconds 27960' ) is broken

interval( 'seconds 27960' ) is broken

From
pgsql-bugs@postgresql.org
Date:
elein (elein@nextbus.com) reports a bug with a severity of 1
The lower the number the more severe it is.

Short Description
interval( 'seconds 27960' ) is broken

Long Description
In 7.0.3, I'm converting seconds from midnight to a time of
day using interval ( 'seconds <val>').  This worked fine in
7.0.3 and gives a Bad interval external representation message
in 7.1.

I'm marking this devastating because it falls under the criteria of not being able to input valid data.  And my
application depends on this conversion.

I see there were a lot of clean up changes in the date/time/stamp functions, but was not able to pinpoint
the change that caused the problem.

A good workaround would reduce this problem to major annoyance.

Sample Code
In 7.0.3:
elein=# select interval( 'seconds 27960');
 ?column?
----------
 07:46
(1 row)

In 7.1:
elein=# select interval( 'seconds 27960');
ERROR:  Bad interval external representation 'seconds 27960'


No file was uploaded with this report

Re: interval( 'seconds 27960' ) is broken

From
Tom Lane
Date:
pgsql-bugs@postgresql.org writes:
> In 7.0.3, I'm converting seconds from midnight to a time of
> day using interval ( 'seconds <val>').  This worked fine in
> 7.0.3 and gives a Bad interval external representation message
> in 7.1.

This has never been the intended or documented format; it should
be '<val> seconds'.  Allowing both is ambiguous, so I'd say that
the behavior change is a correct one.

            regards, tom lane

Re: interval( 'seconds 27960' ) is broken

From
Thomas Lockhart
Date:
> > In 7.0.3, I'm converting seconds from midnight to a time of
> > day using interval ( 'seconds <val>').  This worked fine in
> > 7.0.3 and gives a Bad interval external representation message
> > in 7.1.
> This has never been the intended or documented format; it should
> be '<val> seconds'.  Allowing both is ambiguous, so I'd say that
> the behavior change is a correct one.

In fact, the leading "seconds" label in the above example was never
actually used. What was happening was that the bare "<val>" was
interpreted as having units of seconds, and the leading label had no
effect.

It may help to notice that interval parsing proceeds from right to left,
mostly to allow the units specifier (e.g. "seconds") to be read before
the actual value. A leading units specifier is simply ignored, since
there is no value to the left for it to apply to.

In 7.1, a unitless number is not allowed for an interval, at least
partly because SQL9x requires time zones to be considered intervals
under some conditions. So the default handling of intervals had to be
consistant with that usage.

I would recommend specifying things as "interval ( '<val> seconds' )".

                      - Thomas