1. 07 Nov, 2007 1 commit
  2. 12 Jun, 2007 1 commit
  3. 29 May, 2007 1 commit
  4. 19 Feb, 2007 1 commit
  5. 16 Feb, 2007 1 commit
    • Bruce Momjian's avatar
      Add two new format fields for use with to_char(), to_date() and · 4ebb0cf9
      Bruce Momjian authored
      to_timestamp():
          - ID for day-of-week
          - IDDD for day-of-year
      
      This makes it possible to convert ISO week dates to and from text
      fully represented in either week ('IYYY-IW-ID') or day-of-year
      ('IYYY-IDDD') format.
      
      I have also added an 'isoyear' field for use with extract / date_part.
      
      Brendan Jurd
      4ebb0cf9
  6. 05 Jan, 2007 1 commit
  7. 18 Oct, 2006 1 commit
    • Tom Lane's avatar
      Fix up timetz input so that a date is required only when the specified · 877f08da
      Tom Lane authored
      timezone actually has a daylight-savings rule.  This avoids breaking
      cases that used to work because they went through the DecodePosixTimezone
      code path.  Per contrib regression failures (mea culpa for not running
      those yesterday...).  Also document the already-applied change to allow
      GMT offsets up to 14 hours.
      877f08da
  8. 16 Sep, 2006 1 commit
  9. 25 Jul, 2006 1 commit
    • Tom Lane's avatar
      Remove hard-wired lists of timezone abbreviations in favor of providing · d8b5c95c
      Tom Lane authored
      configuration files that can be altered by a DBA.  The australian_timezones
      GUC setting disappears, replaced by a timezone_abbreviations setting (set this
      to 'Australia' to get the effect of australian_timezones).  The list of zone
      names defined by default has undergone a bit of cleanup, too.  Documentation
      still needs some work --- in particular, should we fix Table B-4, or just get
      rid of it?  Joachim Wieland, with some editorializing by moi.
      d8b5c95c
  10. 06 Jun, 2006 1 commit
  11. 05 Mar, 2006 1 commit
  12. 15 Oct, 2005 1 commit
  13. 23 Jul, 2005 1 commit
  14. 22 Jul, 2005 1 commit
  15. 26 May, 2005 1 commit
    • Neil Conway's avatar
      Adjust datetime parsing to be more robust. We now pass the length of the · 63e0d612
      Neil Conway authored
      working buffer into ParseDateTime() and reject too-long input there,
      rather than checking the length of the input string before calling
      ParseDateTime(). The old method was bogus because ParseDateTime() can use
      a variable amount of working space, depending on the content of the
      input string (e.g. how many fields need to be NUL terminated). This fixes
      a minor stack overrun -- I don't _think_ it's exploitable, although I
      won't claim to be an expert.
      
      Along the way, fix a bug reported by Mark Dilger: the working buffer
      allocated by interval_in() was too short, which resulted in rejecting
      some perfectly valid interval input values. I added a regression test for
      this fix.
      63e0d612
  16. 24 May, 2005 1 commit
  17. 31 Dec, 2004 1 commit
    • PostgreSQL Daemon's avatar
      · 2ff50159
      PostgreSQL Daemon authored
      Tag appropriate files for rc3
      
      Also performed an initial run through of upgrading our Copyright date to
      extend to 2005 ... first run here was very simple ... change everything
      where: grep 1996-2004 && the word 'Copyright' ... scanned through the
      generated list with 'less' first, and after, to make sure that I only
      picked up the right entries ...
      2ff50159
  18. 29 Aug, 2004 2 commits
  19. 03 Jun, 2004 1 commit
    • Tom Lane's avatar
      Adjust our timezone library to use pg_time_t (typedef'd as int64) in · 921d749b
      Tom Lane authored
      place of time_t, as per prior discussion.  The behavior does not change
      on machines without a 64-bit-int type, but on machines with one, which
      is most, we are rid of the bizarre boundary behavior at the edges of
      the 32-bit-time_t range (1901 and 2038).  The system will now treat
      times over the full supported timestamp range as being in your local
      time zone.  It may seem a little bizarre to consider that times in
      4000 BC are PST or EST, but this is surely at least as reasonable as
      propagating Gregorian calendar rules back that far.
      
      I did not modify the format of the zic timezone database files, which
      means that for the moment the system will not know about daylight-savings
      periods outside the range 1901-2038.  Given the way the files are set up,
      it's not a simple decision like 'widen to 64 bits'; we have to actually
      think about the range of years that need to be supported.  We should
      probably inquire what the plans of the upstream zic people are before
      making any decisions of our own.
      921d749b
  20. 21 May, 2004 1 commit
  21. 19 Jan, 2004 1 commit
    • Tom Lane's avatar
      Repair problem identified by Olivier Prenant: ALTER DATABASE SET search_path · 9bd681a5
      Tom Lane authored
      should not be too eager to reject paths involving unknown schemas, since
      it can't really tell whether the schemas exist in the target database.
      (Also, when reading pg_dumpall output, it could be that the schemas
      don't exist yet, but eventually will.)  ALTER USER SET has a similar issue.
      So, reduce the normal ERROR to a NOTICE when checking search_path values
      for these commands.  Supporting this requires changing the API for GUC
      assign_hook functions, which causes the patch to touch a lot of places,
      but the changes are conceptually trivial.
      9bd681a5
  22. 29 Nov, 2003 1 commit
    • PostgreSQL Daemon's avatar
      · 55b11325
      PostgreSQL Daemon authored
      make sure the $Id tags are converted to $PostgreSQL as well ...
      55b11325
  23. 27 Aug, 2003 1 commit
  24. 05 Aug, 2003 1 commit
  25. 04 Aug, 2003 2 commits
  26. 17 Jul, 2003 2 commits
  27. 18 May, 2003 1 commit
    • Tom Lane's avatar
      Add code to test for unknown timezone names (following some ideas from · 6d7ff848
      Tom Lane authored
      Ross Reedstrom, a couple months back) and to detect timezones that are
      using leap-second timekeeping.  The unknown-zone-name test is pretty
      heuristic and ugly, but it seems better than the old behavior of just
      switching to GMT given a bad name.  Also make DecodePosixTimezone() a
      tad more robust.
      6d7ff848
  28. 18 Apr, 2003 1 commit
  29. 04 Apr, 2003 1 commit
  30. 20 Feb, 2003 1 commit
  31. 19 Feb, 2003 1 commit
    • Bruce Momjian's avatar
      The following patches eliminate the overflows in the j2date() and date2j() · a286f732
      Bruce Momjian authored
      functions which limited the maximum date for a timestamp to AD 1465001.
      The new limit is AD 5874897.
      The files affected are:
      
      doc/src/sgml/datatype.sgml:
          Documentation change due to patch. Included is a notice about
          the reduced range when using an eight-byte integer for timestamps.
      
      src/backend/utils/adt/datetime.c:
          Replacement functions for j2date() and date2j() functions.
      
      src/include/utils/datetime.h:
          Corrected a bug with the limit on the earliest possible date,
          Nov 23,-4713 has a Julian day count of -1. The earliest possible
          date should be Nov 24, -4713 with a day count of 0.
      
      src/test/regress/expected/horology-no-DST-before-1970.out:
      src/test/regress/expected/horology-solaris-1947.out:
      src/test/regress/expected/horology.out:
          Copies of expected output for regression testing.
          Note: Only horology.out has been physically tested. I do not have access
          to a Solaris box and I don't know how to provoke the "pre-1970" test.
      
      src/test/regress/sql/horology.sql:
          Added some test cases to check extended range.
      
      John Cochran
      a286f732
  32. 16 Jan, 2003 1 commit
    • Tom Lane's avatar
      Repair an embarrassingly large number of alphabetization mistakes in the · cb23b841
      Tom Lane authored
      datetime token tables.  Even more embarrassing, the regression tests
      revealed some of the problems --- but evidently the bogus output wasn't
      questioned.  Add code to postmaster startup to directly check the tables
      for correct ordering, in hopes of not being embarrassed like this again.
      cb23b841
  33. 04 Sep, 2002 1 commit
  34. 20 Jun, 2002 1 commit
  35. 11 Jun, 2002 1 commit
    • Jan Wieck's avatar
      Katherine Ward wrote: · 469cb65a
      Jan Wieck authored
      > Changes to avoid collisions with WIN32 & MFC names...
      > 1.  Renamed:
      >       a.  PROC => PGPROC
      >       b.  GetUserName() => GetUserNameFromId()
      >       c.  GetCurrentTime() => GetCurrentDateTime()
      >       d.  IGNORE => IGNORE_DTF in include/utils/datetime.h & utils/adt/datetim
      >
      > 2.  Added _P to some lex/yacc tokens:
      >       CONST, CHAR, DELETE, FLOAT, GROUP, IN, OUT
      
      Jan
      469cb65a
  36. 17 May, 2002 1 commit
    • Tom Lane's avatar
      Merge the last few variable.c configuration variables into the generic · f0811a74
      Tom Lane authored
      GUC support.  It's now possible to set datestyle, timezone, and
      client_encoding from postgresql.conf and per-database or per-user
      settings.  Also, implement rollback of SET commands that occur in a
      transaction that later fails.  Create a SET LOCAL var = value syntax
      that sets the variable only for the duration of the current transaction.
      All per previous discussions in pghackers.
      f0811a74
  37. 21 Apr, 2002 1 commit
    • Thomas G. Lockhart's avatar
      Support alternate storage scheme of 64-bit integer for date/time types. · 547df0cc
      Thomas G. Lockhart authored
       Use "--enable-integer-datetimes" in configuration to use this rather
       than the original float8 storage. I would recommend the integer-based
       storage for any platform on which it is available. We perhaps should
       make this the default for the production release.
      Change timezone(timestamptz) results to return timestamp rather than
       a character string. Formerly, we didn't have a way to represent
       timestamps with an explicit time zone other than freezing the info into
       a string. Now, we can reasonably omit the explicit time zone from the
       result and return a timestamp with values appropriate for the specified
       time zone. Much cleaner, and if you need the time zone in the result
       you can put it into a character string pretty easily anyway.
      Allow fractional seconds in date/time types even for dates prior to 1BC.
      Limit timestamp data types to 6 decimal places of precision. Just right
       for a micro-second storage of int8 date/time types, and reduces the
       number of places ad-hoc rounding was occuring for the float8-based types.
      Use lookup tables for precision/rounding calculations for timestamp and
       interval types.  Formerly used pow() to calculate the desired value but
       with a more limited range there is no reason to not type in a lookup
       table. Should be *much* better performance, though formerly there were
       some optimizations to help minimize the number of times pow() was called.
      Define a HAVE_INT64_TIMESTAMP variable. Based on the configure option
       "--enable-integer-datetimes" and the existing internal INT64_IS_BUSTED.
      Add explicit date/interval operators and functions for addition and
       subtraction. Formerly relied on implicit type promotion from date to
       timestamp with time zone.
      Change timezone conversion functions for the timetz type from "timetz()"
       to "timezone()". This is consistant with other time zone coersion
       functions for other types.
      Bump the catalog version to 200204201.
      Fix up regression tests to reflect changes in fractional seconds
       representation for date/times in BC eras.
      All regression tests pass on my Linux box.
      547df0cc