Обсуждение: interval( 'seconds 27960' ) is broken

Поиск
Список
Период
Сортировка

interval( 'seconds 27960' ) is broken

От
pgsql-bugs@postgresql.org
Дата:
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

От
Tom Lane
Дата:
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

От
Thomas Lockhart
Дата:
> > 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