* 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).
to 10, and be consistent about whether it counts the trailing null (it
does not). Also increase MAXDATELEN to be sure no buffer overflows are
caused by the longer MAXTZLEN.
Transform datetime and timespan into timestamp and interval.
Deprecate datetime and timespan, though translate to new types in gram.y.
Transform all datetime and timespan catalog entries into new types.
Make "INTERVAL" reserved word allowed as a column identifier in gram.y.
Remove dt.h, dt.c files, and retarget datetime.h, datetime.c as utility
routines for all date/time types.
date.{h,c} now deals with date, time types.
timestamp.{h,c} now deals with timestamp, interval types.
nabstime.{h,c} now deals with abstime, reltime, tinterval types.
Make NUMERIC a known native type for purposes of type coersion. Not tested.
I was able to crash postgres 6.5.3 when I did an 'alter user' command.
After I started a debugger I found the problem in the timezone handling
of
datetime (my Linux box lost its timezone information, that's how the
problem occurred).
Only 7 bytes are reserved for the timezone, without checking for
boundaries.
Attached is a patch that fixes this problem and emits a NOTICE if a
timezone is encountered that is longer than MAXTZLEN bytes, like this:
Jeroen van Vianen
Ok. I made patches replacing all of "#if FALSE" or "#if 0" to "#ifdef
NOT_USED" for current. I have tested these patches in that the
postgres binaries are identical.
to give HAVE_TM_ZONE priority. This fixes glibc2 machines and any other
machine which passes both tests in configure.
Repair HAVE_TM_ZONE code which stuffs tm structure with date type values.
Same problems as were originally there before v6.1, but never noticed.
Thanks to Oleg for nagging :)
where you state a format and arguments. the old behavior required
each appendStringInfo to have to have a sprintf() before it if any
formatting was required.
Also shortened several instances where there were multiple appendStringInfo()
calls in a row, doing nothing more then adding one more word to the String,
instead of doing them all in one call.
over HAVE_INT_TIMEZONE. This may help out linux/glibc2 and Dec Alpha.
Included #error precompiler macros to catch cases where neither is defined
but USE_POSIX_TIME is (shouldn't happen). Hopefully this isn't just
a gcc-ism.
Add type conversion functions for floating point numbers.
Check for zero in unary minus floating point code (IEEE allows an
explicit negative zero which looks ugly in a query result!).
Ensure circle type has non-negative radius.
Here are patches which should help fix timezone problems in the
datetime and abstime code. Also, I repatched varlena.c to add in
some comments and a little error checking on top of Vadim's earlier
repairs. There are slight mods to the circle data type to have the
distance operator between circles measure the distance between
closest points rather than between centers.
Subject: [PATCHES] date/time timezone patches (mail bounced?)
Here are some hacks to get timezone behavior for the various time
data types to be compatible with v6.0. Although we have some hooks
already installed to get timezone info from the client to the
server, it still isn't clear if that can correctly transfer enough
timezone info to make the behavior the same as if timezone info
were derived from the server as is now the case. We certainly
won't resolve it in a day, so I think we are stuck with server-only
timezones for v6.1.
