1. 03 Jun, 2009 6 commits
  2. 02 Jun, 2009 3 commits
  3. 01 Jun, 2009 2 commits
    • Tom Lane's avatar
      Change AdjustIntervalForTypmod to not discard higher-order field values on the · bac2ad38
      Tom Lane authored
      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.
      bac2ad38
    • Tom Lane's avatar
      Fix DecodeInterval to report an error for multiple occurrences of DAY, WEEK, · b3b89fd1
      Tom Lane authored
      YEAR, DECADE, CENTURY, or MILLENIUM fields, just as it always has done for
      other types of fields.  The previous behavior seems to have been a hack to
      avoid defining bit-positions for all these field types in DTK_M() masks,
      rather than something that was really considered to be desired behavior.
      But there is room in the masks for these, and we really need to tighten up
      at least the behavior of DAY and YEAR fields to avoid unexpected behavior
      associated with the 8.4 changes to interpret ambiguous fields based on the
      interval qualifier (typmod) value.  Per my example and proposed patch.
      b3b89fd1
  4. 31 May, 2009 1 commit
  5. 29 May, 2009 1 commit
  6. 28 May, 2009 2 commits
  7. 27 May, 2009 8 commits
  8. 26 May, 2009 4 commits
  9. 24 May, 2009 2 commits
  10. 21 May, 2009 3 commits
  11. 20 May, 2009 5 commits
  12. 19 May, 2009 3 commits