]> granicus.if.org Git - postgresql/commit
Change AdjustIntervalForTypmod to not discard higher-order field values on the
authorTom Lane <tgl@sss.pgh.pa.us>
Mon, 1 Jun 2009 23:55:15 +0000 (23:55 +0000)
committerTom Lane <tgl@sss.pgh.pa.us>
Mon, 1 Jun 2009 23:55:15 +0000 (23:55 +0000)
commitbac2ad38ea944e0acb1dd4b99a870016dd189c16
tree8f2f8e4bc1e9260dd0fd488ead45e823aa7af1b5
parentb3b89fd1f1ab3b1f3052695e51a94713921808a5
Change AdjustIntervalForTypmod to not discard higher-order field values on the
grounds that they don't fit into the specified interval qualifier (typmod).
This behavior, while of long standing, is clearly wrong per spec --- for
example the value INTERVAL '999' SECOND means 999 seconds and should not be
reduced to less than 60 seconds.

In some cases there could be grounds to raise an error if higher-order field
values are not given as zero; for example '1 year 1 month'::INTERVAL MONTH
should arguably be taken as an error rather than equivalent to 13 months.
However our internal representation doesn't allow us to do that in a fashion
that would consistently reject all and only the cases that a strict reading
of the spec would suggest.  Also, seeing that for example INTERVAL '13' MONTH
will print out as '1 year 1 mon', we have to be careful not to create a
situation where valid data will fail to dump and reload.  The present patch
therefore takes the attitude of not throwing an error in any such case.
We might want to revisit that in future but it would take more redesign
than seems prudent in late beta.

Per a complaint from Sebastien Flaesch and subsequent discussion.  While
at other times we might have just postponed such an issue to the next
development cycle, 8.4 already has changed the parsing of interval literals
quite a bit in an effort to accept all spec-compliant cases correctly.
This seems like a change that should be part of that rather than coming
along later.
src/backend/utils/adt/timestamp.c
src/test/regress/expected/interval.out
src/test/regress/sql/interval.sql