diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml index 20863a1532..646639409f 100644 --- a/doc/src/sgml/datatype.sgml +++ b/doc/src/sgml/datatype.sgml @@ -1,5 +1,5 @@ @@ -229,13 +229,19 @@ $Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.63 2001/09/13 15:55:22 pe time with time zone - + timetz time of day, including time zone + + timestamp without time zone + timestamp + date and time + + timestamp [ with time zone ] - + timestamptz date and time @@ -981,7 +987,7 @@ SELECT b, char_length(b) FROM test2; - timestamp + timestamp without time zone both date and time 8 bytes 4713 BC @@ -990,10 +996,10 @@ SELECT b, char_length(b) FROM test2; timestamp [ with time zone ] - date and time with time zone + both date and time 8 bytes - 1903 AD - 2037 AD + 4713 BC + AD 1465001 1 microsecond / 14 digits @@ -1034,21 +1040,37 @@ SELECT b, char_length(b) FROM test2; - To ensure compatibility to earlier versions of Postgres - we also continue to provide datetime (equivalent to timestamp) and - timespan (equivalent to interval), - however support for these is now restricted to having an - implicit translation to timestamp and - interval. - The types abstime - and reltime are lower precision types which are used internally. - You are discouraged from using any of these types in new - applications and are encouraged to move any old - ones over when appropriate. Any or all of these internal types might disappear in a future release. + Time zones, and time zone conventions, are influenced by + political conventions, not just physical effects. Time zones have + become somewhat standardized during the 1900's, but continue to + be prone to arbitrary changes with time. + PostgreSQL uses your operating + system's underlying features to provide time zone + support, and these systems usually contain information for only + the time period 1902 through 2038 (corresponding to the full + range of conventional Unix system time). + timestamp with time zone will use time zone + information only within that year range, and assumes that times + are in UTC outside that range. + + To ensure compatibility to earlier versions of Postgres + we also continue to provide datetime + (equivalent to timestamp) and + timespan (equivalent to interval), + however support for these is now restricted to having an + implicit translation to timestamp and + interval. + The types abstime + and reltime are lower precision types which are used internally. + You are discouraged from using any of these types in new + applications and are encouraged to move any old + ones over when appropriate. Any or all of these internal types + might disappear in a future release. + Date/Time Input @@ -1266,6 +1288,10 @@ SELECT b, char_length(b) FROM test2; time data type + + time without time zone + time + Per SQL99, this type can be referenced as time and @@ -1330,11 +1356,21 @@ SELECT b, char_length(b) FROM test2; <type>time with time zone</type> + + time with time zone + data type + + + time + data type + + This type is defined by SQL92, but the definition exhibits - fundamental deficiencies that render the type nearly useless. In + properties which lead to questionable usefulness. In most cases, a combination of date, - time, and timestamp + time, timestamp without time zone + and timestamp with time zone should provide a complete range of date/time functionality required by any application. @@ -1382,7 +1418,44 @@ SELECT b, char_length(b) FROM test2; - <type>timestamp</type> + <type>timestamp without time zone</type> + + + timestamp without time zone + data type + + + + Valid input for the timestamp without time zone + type consists of a concatenation + of a date and a time, followed by an optional AD or + BC, followed by an optional time zone. (See below.) + Thus + + +1999-01-08 04:05:06 + + + is a valid timestamp without time zone value that + is ISO-compliant. + In addition, the wide-spread format + + +January 8 04:05:06 1999 PST + + is supported. + + + + For timestamp without time zone, any explicit time + zone specified in the input is silently swallowed. That is, the + resulting date/time value is derived from the explicit date/time + fields in the input value, and is not adjusted for time zone. + + + + + <type>timestamp with time zone</type> timestamp @@ -1500,10 +1573,12 @@ January 8 04:05:06 1999 PST + epoch 1970-01-01 00:00:00+00 (Unix system time zero) diff --git a/doc/src/sgml/datetime.sgml b/doc/src/sgml/datetime.sgml index 5fceb8ce7b..23e6c587a6 100644 --- a/doc/src/sgml/datetime.sgml +++ b/doc/src/sgml/datetime.sgml @@ -1,5 +1,5 @@ @@ -14,7 +14,7 @@ Date/time details - Postgres must have internal tabular + Postgres contains internal tabular information for time zone decoding, since there is no *nix standard system interface to provide access to general, cross-timezone information. The underlying OS is used to diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml index 0a8b2f6d73..0de8db1538 100644 --- a/doc/src/sgml/func.sgml +++ b/doc/src/sgml/func.sgml @@ -1,4 +1,4 @@ - + Functions and Operators @@ -26,10 +26,9 @@ the functions and operators described in this chapter, with the exception of the most trivial arithmetic and comparison operators and some explicitly marked functions, are not specified by the SQL - standard. However, many other RDBMS packages provide a lot of the - same or similar functions, and some of the ones provided in - Postgres have in fact been inspired by - other implementations. + standard. Some of this extended functionality is present in other + RDBMS products, and in many cases this + functionality is compatible and consistant between various products. @@ -302,8 +301,16 @@ Mathematical Functions and Operators + + Mathematical operators are provided for many + PostgreSQL types. For types without + common mathematical conventions for all possible permutations + (e.g. date/time types) we + describe the actual behavior in subsequent sections. + + - Mathematical Operators + Mathematical Operators @@ -1542,7 +1549,7 @@ - Formatting Functions + Multi-type Formatting Functions formatting @@ -2252,18 +2259,99 @@ - Date/Time Functions + Date/Time Functions and Operators shows the available - functions for date/time value processing. The basic arithmetic - operators (+, *, etc.) are - also available. For formatting functions, refer to illustrates the + behaviors of the basic arithmetic + operators (+, *, etc.). + For formatting functions, refer to . You should be familiar with the background information on date/time data types (see ). + + The date/time operators described below behave similarly for types + involving time zones as well as those without. + +
+ Date/Time Operators + + + + + Name + Example + Result + + + + + + + + timestamp '2001-09-28 01:00' + interval '23 hours' + timestamp '2001-09-29 00:00' + + + + + + date '2001-09-28' + interval '1 hour' + timestamp '2001-09-28 01:00' + + + + + + time '01:00' + interval '3 hours' + time '04:00' + + + + - + timestamp '2001-09-28 23:00' - interval '23 hours' + timestamp '2001-09-28' + + + + - + date '2001-09-28' + interval '1 hour' + timestamp '2001-09-27 23:00' + + + + - + time '05:00' + interval '2 hours' + time '03:00' + + + + - + interval '2 hours' - time '05:00' + time '03:00:00' + + + + * + interval '1 hour' * int '3' + interval '03:00' + + + + / + interval '1 hour' / int '3' + interval '00:20' + + + +
+ + + + The date/time functions are summarized below, with additional + details in subsequent sections. + Date/Time Functions @@ -2431,7 +2519,7 @@
- + <function>EXTRACT</function>, <function>date_part</function> @@ -2546,7 +2634,7 @@ SELECT EXTRACT(DOY FROM TIMESTAMP '2001-02-16 20:38:40'); For date and timestamp values, the - number of seconds since 1970-01-01 00:00:00 (Result may be + number of seconds since 1970-01-01 00:00:00-00 (Result may be negative.); for interval values, the total number of seconds in the interval diff --git a/doc/src/sgml/manage.sgml b/doc/src/sgml/manage.sgml index f89e316f90..0b58ddd76b 100644 --- a/doc/src/sgml/manage.sgml +++ b/doc/src/sgml/manage.sgml @@ -1,5 +1,5 @@ @@ -31,7 +31,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/Attic/manage.sgml,v 1.16 2001/09/13 15:55:2 Database Creation - Databases are created by the create database issued from + Databases are created by the CREATE DATABASE issued from within Postgres. createdb is a command-line utility provided to give the same functionality from outside Postgres. diff --git a/doc/src/sgml/recovery.sgml b/doc/src/sgml/recovery.sgml index ba19b6ed6c..e4e74fdfd2 100644 --- a/doc/src/sgml/recovery.sgml +++ b/doc/src/sgml/recovery.sgml @@ -1,8 +1,117 @@ - -Database Recovery + + Database Failures - -This section needs to be written. Volunteers? - + + Database failures (or the possibility of such) must be assumed to be + lurking, ready to strike at some time in the future. A prudent + database administrator will plan for the inevitability of failures + of all possible kinds, and will have appropriate plans and + procedures in place before the failure occurs. + - + + Database recovery is necessary in the event of hardware or software + failure. There are several categories of failures; some of these + require relatively minor adjustments to the database, while others + may depend on the existance of previously prepared database dumps + and other recovery data sets. It should be emphasized that if your + data is important and/or difficult to regenerate, then you should + have considered and prepared for various failure scenarios. + + + + Disk Filled + + + A filled data disk may result in subsequent corruption of database + indices, but not of the fundamental data tables. If the WAL files + are on the same disk (as is the case for a default configuration) + then a filled disk during database initialization may result in + corrupted or incomplete WAL files. This failure condition is + detected and the database will refuse to start up. You must free + up additional space on the disk (or move the WAL area to another + disk; see ) and then restart the + postmaster to recover from this condition. + + + + + Disk Failed + + + Failure of any disk (or of a logical storage device such as a RAID + subsystem) involved with an active database will require + that the database be recovered from a previously prepared database + dump. This dump must be prepared using + pg_dumpall, and updates to the database + occuring after the database installation was dumped will be lost. + + + + + File Corrupted + + + + + + + Table Corrupted + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Database Recovery + + + Database recovery is necessary in the event of hardware or software + failure. There are several categories of failures; some of these + require relatively minor adjustments to the database, while others + may depend on the existance of previously prepared database dumps + and other recovery data sets. It should be emphasized that if your + data is important and/or difficult to regenerate, then you should + have considered and prepared for various failure scenarios. + + + + + +