and should do now that we control our own destiny for timezone handling,
but this commit gets the bulk of the picayune diffs in place.
Magnus Hagander and Tom Lane.
SQLSTATE error codes required by SQL99 (invalid format, datetime field
overflow, interval field overflow, invalid time zone displacement value).
Also emit a HINT about DateStyle in cases where it seems appropriate.
Per recent gripes.
datatype by array_eq and array_cmp; use this to solve problems with memory
leaks in array indexing support. The parser's equality_oper and ordering_oper
routines also use the cache. Change the operator search algorithms to look
for appropriate btree or hash index opclasses, instead of assuming operators
named '<' or '=' have the right semantics. (ORDER BY ASC/DESC now also look
at opclasses, instead of assuming '<' and '>' are the right things.) Add
several more index opclasses so that there is no regression in functionality
for base datatypes. initdb forced due to catalog additions.
for the sign of timezone offsets, ie, positive is east from UTC. These
were previously out of step with other operations that accept or show
timezones, such as I/O of timestamptz values.
Per recent discussion on pgsql-general, this is appropriate for spec
compliance, and has the nice side-effect of easing porting from old
pg_dump files that exhibit the 59.999=>60.000 roundoff problem.
setting timezone-related variables during transaction start. They were
not used anyway in platforms that HAVE_TM_ZONE or HAVE_INT_TIMEZONE,
which it appears is *all* the platforms we are currently supporting.
For platforms that have neither, we now only support UTC or numeric-
offset-from-UTC timezones.
answer when SET TIMEZONE has been done since the start of the current
transaction. Per bug report from Robert Haas.
I plan some futher cleanup in HEAD, but this is a low-risk patch for
the immediate issue in 7.3.
anymore given the mktime() workaround now done in DetermineLocalTimeZone.
This has now been confirmed by Robert Bruccoleri for Irix, and I'm going
to extrapolate to AIX as well.
pointed out by Barry Lind: UPDATE bigintcol = 10000000000 fails because
the constant is initially taken as float8. We really need a better way,
but it's not gonna happen for 7.3.
Also, remove int4reltime() function, which is redundant with the
existing binary-compatibility coercion path from int4 to reltime,
and probably has been unreachable code for a long while.
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.
> 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
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.
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.
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.
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.
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.
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.
Tom Lane
PostgreSQL Daemon
Peter Eisentraut
Bruce Momjian
Thomas G. Lockhart
Jan Wieck
Tatsuo Ishii