noise words for the last twelve years, for compatibility with Berkeley-era
output formatting of the special INVALID values for those datatypes.
Considering that the datatypes themselves have been deprecated for awhile,
this is taking backwards compatibility a little far. Per gripe from Josh
Berkus.
outside the 32-bit-time_t range. Also, refer to Olson's tz database
as the 'zoneinfo' database, a name that upstream sometimes uses, not
'zic database' which they never use.
to ensure that the resulting webpages have predictable URLs, instead of
ever-changing numeric IDs. The new contrib docs were the biggest
offender, but some old stuff had the problem too. Also, rename a couple
of new contrib sgml files for consistency's sake.
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
Also update two error messages mentioned in the documenation to match.
input routines. Remove the former "DecodePosixTimezone" function in favor of
letting the zic code handle POSIX-style zone specs (see tzparse()). In
particular this means that "PST+3" now means the same as "-03", whereas it
used to mean "-11" --- the zone abbreviation is effectively just a noise word
in this syntax. Make sure that all named and POSIX-style zone names will be
parsed as a single token. Fix long-standing bogosities in printing and input
of fractional-hour timezone offsets (since the tzparse() code will accept
these, we'd better make 'em work). Also correct an error in the original
coding of the zic-zone-name patch: in "timestamp without time zone" input,
zone names are supposed to be allowed but ignored, but the coding was such
that the zone changed the interpretation anyway.
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.
compatibility for release 7.2 and earlier. I have not altered any
mentions of release 7.3 or later. The release notes were not modified,
so the changes are still documented, just not in the main docs.
in the zic database or zone names found in the date token table. This
preserves the old ability to do AT TIME ZONE 'PST' along with the new
ability to do AT TIME ZONE 'PST8PDT'. Per gripe from Bricklen Anderson.
Also, fix some inconsistencies in usage of TZ_STRLEN_MAX --- the old
code had the potential for one-byte buffer overruns, though given
alignment considerations it's unlikely there was any real risk.
"AT TIME ZONE", and not just the shorlist previously available. For
example:
SELECT CURRENT_TIMESTAMP AT TIME ZONE 'Europe/London';
works fine now. It will also obey whatever DST rules were in effect at
just that date, which the previous implementation did not.
It also supports the AT TIME ZONE on the timetz datatype. The whole
handling of DST is a bit bogus there, so I chose to make it use whatever
DST rules are in effect at the time of executig the query. not sure if
anybody is actuallyi *using* timetz though, it seems pretty
unpredictable just because of this...
Magnus Hagander
---------------------------------------------------------------------------
1. In keeping with the recent discussion that there should be more
said about views, stored procedures, and triggers, in the tutorial, I
have added a bit of verbiage to that end.
2. Some formatting changes to the datetime discussion, as well as
addition of a citation of a relevant book on calendars.
Christopher Browne
said about views, stored procedures, and triggers, in the tutorial, I
have added a bit of verbiage to that end.
2. Some formatting changes to the datetime discussion, as well as
addition of a citation of a relevant book on calendars.
Christopher Browne
heuristic determination of day vs month in date/time input. Add the
ability to specify that input is interpreted as yy-mm-dd order (which
formerly worked, but only for yy greater than 31). DateStyle's input
component now has the preferred spellings DMY, MDY, or YMD; the older
keywords European and US are now aliases for the first two of these.
Per recent discussions on pgsql-general.
Update the list of recognized time zones.
Document the range of arguments allowed for SET TIME ZONE.
Still need to add info on other date/time symbols (e.g. "AM", "T")
and to freshen the docs on the date/time parsing rules.
Chapter 4
String Operators
Table 4.7: Other String Functions
strpos is missing the result in the result column, it should be 2
Also to_ascii might need a result but maybe not.
Appendix A
In the Time Zone Table
Greenwich is spelled Greenwish
David Aldrich
Bruce Momjian
Peter Eisentraut
Magnus Hagander
Tom Lane
Neil Conway
PostgreSQL Daemon
Thomas G. Lockhart