case for timestamptz input, and differently wrong answers in the float-
timestamp case for timestamp input.

because c.h has sys/types.h.

array header, and to compute sizing and alignment of array elements
the same way normal tuple access operations do --- viz, using the
tupmacs.h macros att_addlength and att_align.  This makes the world
safe for arrays of cstrings or intervals, and should make it much
easier to write array-type-polymorphic functions; as examples see
the cleanups of array_out and contrib/array_iterator.  By Joe Conway
and Tom Lane.

 strings. Should go back in and look at doing this a bit more elegantly
 and (hopefully) cheaper. Probably not too bad anyway, but it seems a
 shame to scan the strings twice: once for length for this buffer overrun
 protection, and once to parse the line.
Remove use of pow() in date/time handling; was already gone from everything
 *but* the time data types.
Define macros for handling typmod manipulation for date/time types.
 Should be more robust than all of that brute-force inline code.
Rename macros for masking and typmod manipulation to put TIMESTAMP_
 or INTERVAL_ in front of the macro name, to reduce the possibility
 of name space collisions.

 integer datetimes. Thanks to Tom Lane for spotting the problem.

 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.

(char != unsigned char, Datum != uint32); make use of new hash code in
dynahash hash tables and hash joins.

o  Change all current CVS messages of NOTICE to WARNING.  We were going
to do this just before 7.3 beta but it has to be done now, as you will
see below.

o Change current INFO messages that should be controlled by
client_min_messages to NOTICE.

o Force remaining INFO messages, like from EXPLAIN, VACUUM VERBOSE, etc.
to always go to the client.

o Remove INFO from the client_min_messages options and add NOTICE.

Seems we do need three non-ERROR elog levels to handle the various
behaviors we need for these messages.

Regression passed.

timestamp/timestamptz combo. Now extract/date_part returns
seconds*1000 or 1000000 + fraction part as the manual stats.
regression test are also fixed.

See the thread in pgsql-hackers:

Subject: Re: [HACKERS] timestamp_part() bug?
Date: Sat, 02 Mar 2002 11:29:53 +0900

 Thanks to Bruce for spotting it and Tom Lane for diagnosing it.
Since horology test output is changing anyway, add some date/time input
 tests to horology.sql. Some of these should move to the tests for the
 individual data types, and we perhaps should add an entire new test
 for "timezone" to allow manipulating the current time zone without
 risking damage to the results of other tests.

 cases which should have worked but did not.
Now supports julian day (J2452271), ISO time labels (T040506) and various
 combinations of spaces and run-togethers of dates, times, and time zones.
All regression tests pass, and I have more tests to add after the 7.2
 release (don't want to require changes to the ancillary horology result
 files until after then).

Per report from Bernd Tegge.

tests pass.

Mask both typmod subfields for INTERVAL to avoid setting the high bit,
 per dire warning from Tom Lane.
Clear tmask for DTK_ISO_TIME case to avoid time zone troubles.
 Symptom reported by Tom Lane.
Clean up checking for valid time zone info in output routine.
 This should now work for both SQL99 and Unix-style time zones.
Put in explicit check for INTERVAL() typmod rounding to avoid accumulating
 cruft in the lower bits. Not sure that this helps, but we'll need to do
 something. The symptom is visible with a query like
 select interval(2) '10000 days 01:02:03.040506';
Regression tests are patched to repair the Tom Lane symptom, and all pass.

 Modified the parser and the SET handlers to use full Node structures
 rather than simply a character string argument.
Implement INTERVAL() YEAR TO MONTH (etc) syntax per SQL99.
 Does not yet accept the goofy string format that goes along with, but
 this should be fairly straight forward to fix now as a bug or later
 as a feature.
Implement precision for the INTERVAL() type.
 Use the typmod mechanism for both of INTERVAL features.
Fix the INTERVAL syntax in the parser:
 opt_interval was in the wrong place.
INTERVAL is now a reserved word, otherwise we get reduce/reduce errors.
Implement an explicit date_part() function for TIMETZ.
 Should fix coersion problem with INTERVAL reported by Peter E.
Fix up some error messages for date/time types.
 Use all caps for type names within message.
Fix recently introduced side-effect bug disabling 'epoch' as a recognized
 field for date_part() etc. Reported by Peter E. (??)
Bump catalog version number.
Rename "microseconds" current transaction time field
 from ...Msec to ...Usec. Duh!
date/time regression tests updated for reference platform, but a few
 changes will be necessary for others.

 per Jan Varga <varga@utcru.sk>
Fix up spacing and formatting.

-infinity and +infinity.  Put TIMESTAMP_NOT_FINITE guard into the routine,
instead of forgetting it at some call sites.  Fixes regression test
failures here.

 time zones.
SQL99 spec requires a default of zero (round to seconds) which is set
 in gram.y as typmod is set in the parse tree. We *could* change to a
 default of either 6 (for internal compatibility with previous versions)
 or 2 (for external compatibility with previous versions).
Evaluate entries in pg_proc wrt the iscachable attribute for timestamp and
 other date/time types. Try to recognize cases where side effects like the
 current time zone setting may have an effect on results to decide whether
 something is cachable or not.

Define a new function, GetCurrentTransactionStartTimeUsec() to get the time
 to this precision.
Allow now() and timestamp 'now' to use this higher precision result so
 we now have fractional seconds in this "constant".
Add timestamp without time zone type.
Move previous timestamp type to timestamp with time zone.
Accept another ISO variant for date/time values: yyyy-mm-ddThh:mm:ss
 (note the "T" separating the day from hours information).
Remove 'current' from date/time types; convert to 'now' in input.
Separate time and timetz regression tests.
Separate timestamp and timestamptz regression test.

 - new millisecond (ms) and microsecond (us) support
 - more robus parsing from string - used is separator checking for
   non-exact formats like to_date('2001-9-1', 'YYYY-MM-DD')
 - SGML docs are included

Karel Zak

routine DetermineLocalTimeZone().  In that routine, be more wary of
broken mktime() implementations than the original code was: don't allow
mktime to change the already-set y/m/d/h/m/s information, and don't
use tm_gmtoff if mktime failed.  Possibly this will resolve some of
the complaints we've been hearing from users of Middle Eastern timezones
on RedHat.

give consistent results for all datatypes.  Types float4, float8, and
numeric were broken for NaN values; abstime, timestamp, and interval
were broken for INVALID values; timetz was just plain broken (some
possible pairs of values were neither < nor = nor >).  Also clean up
text, bpchar, varchar, and bit/varbit to eliminate duplicate code and
thereby reduce the probability of similar inconsistencies arising in
the future.

as previously discussed.

It makes AIX and IRIX not use DST for dates before 1970.

The following expected files need to be removed from the regression tests,
they contain wrong results and are not needed any more.

src/test/regress/expected/horology-1947-PDT.out
src/test/regress/expected/tinterval-1947-PDT.out
src/test/regress/expected/abstime-1947-PDT.out

Zeugswetter Andreas

 mixed-signs. Previous effort left way too many minus signs, and was at
 least as broken as the one before that :(
Clean up "ISO-style" time interval representation to omit zero fields if
 there is at least one non-zero field. Supress some leading plus signs
 when not necessary for clarity.
Replace every #ifdef __CYGWIN__ block with a cleaner TIMEZONE_GLOBAL macro
 defined in datetime.h.

 Not sure why some were this way, and others were already correct, but it
 seems to have been like this for several years.
This caused problems on a few damaged platforms like AIX and IRIX which do
 not support DST calculations for years before 1970.
Thanks to Andreas Zeugswetter <ZeugswetterA@wien.spardat.at> for finding
 the problem.

Previous result did not have correct month boundaries so anything near edge
 cases was suspect (e.g. April was in Q1 and July, August were lumped into
 Q2).
Thanks to Denis Osadchy <osadchy@turbo.nsk.su> for the report.

As I read it, the spec requires a non-null result in some cases where
one of the inputs is NULL: specifically, if the other endpoint of that
interval is between the endpoints of the other interval, then the result
is known TRUE despite the missing endpoint.  The spec could've been a
lot simpler if they did not intend this behavior.
I did not force an initdb for this change, but if you don't do one you'll
still see the old strict-function behavior.

values, whether the local char type is signed or not.  This is necessary
for portability.  Per discussion on pghackers around 9/16/00.

Define conversions to and from text for date, time, and timetz.
Have millisecond and microsecond return full # of seconds in those units.
 Previously, only returned full fractional part in those units.

 Previously, all fields were unsigned, with only a trailing "ago" to
 indicate negative intervals. Now, ISO format does not use "ago", and
 and the traditional PostgreSQL format has the first numeric field unsigned
 with "ago" supporting that field. So "1 month - 2 days ago" is two days
 less than a month in the past.
Fix interval arithmetic across daylight savings time boundaries.
 Previously, most math across boundaries introduced a one hour offset.
Allow some date/time functions to return NULL if called with NULL args.
Implement functions for AT TIME ZONE support.
Support "SAT" as an Australian time zone if USE_AUSTRALIAN_RULES
 is defined.

equivalent.

In linux.h there were some #undef HAVE_INT_TIMEZONE, which are useless
because HAVE_TM_ZONE overrides it anyway, and messing with configure
results isn't cool.

  - full support for IW (ISO week) and vice versa conversion for IW too
    (the to_char 'week' support is now complete and I hope correct).

  Thomas, I use for IW code from timestamp.c, for this I create separate
  function date2isoweek() from original 'case DTK_WEEK:' code in the
  timestamp_part(). I mean will better use one code for same feature in
  date_part() and in to_char(). The isoweek2date() is added to timestamp.c
  too. Right?

  IMHO in 7.1 will all to_char's features complete. It is cca 41 templates
  for date/time and cca 21 for numbers.

 * to_ascii:

   - gcc, is it correct now? :-)


  In the patch is documentation for to_char's IW and for to_ascii().

                                                        Karel

There's now only one transition value and transition function.
NULL handling in aggregates is a lot cleaner.  Also, use Numeric
accumulators instead of integer accumulators for sum/avg on integer
datatypes --- this avoids overflow at the cost of being a little slower.
Implement VARIANCE() and STDDEV() aggregates in the standard backend.

Also, enable new LIKE selectivity estimators by default.  Unrelated
change, but as long as I had to force initdb anyway...

* the result is not recorded anywhere
* the result is not used anywhere
* the result is only used in some places, whereas others have been getting away with it
* the result is used improperly

Also make command line options handling a little better (e.g., --disable-locale,
while redundant, should really still *dis*able).