+
- See
- for details on time zones recognized by
Postgres.
-
-
+
+
interval
- If the compiler option USE_AUSTRALIAN_RULES is set
- then EST refers to Australia Eastern Std Time,
- which has an offset of +10:00 hours from UTC.
+ intervals can be specified with the following syntax:
+ Quantity Unit [Quantity Unit...] [Direction]
+@ Quantity Unit [Direction]
+
+ where: Quantity is ..., -1,
+ 0, 1, 2, ...;
+ Unit is second,
+ minute, hour, day,
+ week, month, year,
+ decade, century, millenium,
+ or abbreviations or plurals of these units;
+ Direction can be ago or
+ empty.
-
-
+
+
+
Special values
+ The following
SQL-compatible functions can be used as date or time
+ input for the corresponding datatype: CURRENT_DATE,
+ CURRENT_TIME, CURRENT_TIMESTAMP.
+
- Australian time zones and their naming variants
- account for fully one quarter of all time zones in the
-
Postgres time zone lookup table.
+
PostgreSQL also supports several special constants for
+ convenience.
+
+
<productname>PostgresSQL</productname> Special Date/Time Constants
+ Constants
+
+
+ |
+ Constant
+ Description
+
+
+
+ |
+ current
+ Current transaction time, deferred
+
+ |
+ epoch
+ 1970-01-01 00:00:00+00 (Unix system time zero)
+
+ |
+ infinity
+ Later than other valid times
+
+ |
+ -infinity
+ Earlier than other valid times
+
+ |
+ invalid
+ Illegal entry
+
+ |
+ now
+ Current transaction time
+
+ |
+ today
+ Midnight today
+
+ |
+ tomorrow
+ Midnight tomorrow
+
+ |
+ yesterday
+ Midnight yesterday
+
+
+
+
+ 'now' is resolved when the value is inserted, 'current'
+ is resolved everytime the value is retrieved. So you probably want to use 'now'
+ in most applications. (Of course you really want to use
+ CURRENT_TIMESTAMP, which is equivalent to 'now'.)
+
+
-
<span class="marked"><type>datetime</type></span>
+
<span class="marked">Date/Time Output</span>
- General-use date and time is input using a wide range of
- styles, including ISO-compatible,
SQL-compatible, traditional
-
Postgres (see section on "absolute time")
- and other permutations of date and time. Output styles can be ISO-compatible,
-
SQL-compatible, or traditional
-
Postgres, with the default set to be compatible
+ Output formats can be set to one of the four styles
+ ISO-8601,
SQL (Ingres), traditional
+ Postgres, and German, using the SET DateStyle.
+ The default is the
ISO format.
+
+
<productname>PostgreSQL</productname> Date/Time Output Styles
+ Styles
+
+
+ |
+ Style Specification
+ Description
+ Example
+
+
+
+ |
+ 'ISO'
+ ISO-8601 standard
+ 1997-12-17 07:37:16-08
+
+ |
+ 'SQL'
+ Traditional style
+ 12/17/1997 07:37:16.00 PST
+
+ |
+ 'Postgres'
+ Original style
+ Wed Dec 17 07:37:16 1997 PST
+
+ |
+ 'German'
+ Regional style
+ 17.12.1997 07:37:16.00 PST
+
+
+
+
- datetime is specified using the following syntax:
-
-Year-Month-Day [ Hour : Minute : Second ] [AD,BC] [ Timezone ]
- YearMonthDay [ Hour : Minute : Second ] [AD,BC] [ Timezone ]
- Month Day [ Hour : Minute : Second ] Year [AD,BC] [ Timezone ]
-where
- Year is 4013 BC, ..., very large
- Month is Jan, Feb, ..., Dec or 1, 2, ..., 12
- Day is 1, 2, ..., 31
- Hour is 00, 02, ..., 23
- Minute is 00, 01, ..., 59
- Second is 00, 01, ..., 59 (60 for leap second)
- Timezone is 3 characters or ISO offset to GMT
-
+ The output of the date and time styles is of course
+ only the date or time part in accordance with the above examples
- Valid dates are from Nov 13 00:00:00 4013 BC GMT to far into the future.
- Timezones are either three characters (e.g. "GMT" or "PST") or ISO-compatible
- offsets to GMT (e.g. "-08" or "-08:00" when in Pacific Standard Time).
- Dates are stored internally in Greenwich Mean Time. Input and output routines
- translate time to the local time zone of the server.
-
-
+ The
SQL style has European and non-European (US) variants,
+ which determines whether month follows day or vica versa. (See also above
+ at Date/Time Input, how this setting affects interpretation of input values.)
-
-
<type>timespan</type>
+
<productname>PostgreSQL</productname> Date Order Conventions
+ Order
+
+
+ |
+ Style Specification
+ Example
+
+
+
+ |
+ European
+ 17/12/1997 15:37:16.00 MET
+
+ |
+ US
+ 12/17/1997 07:37:16.00 PST
+
+
+
+
+
- General-use time span is input using a wide range of
- syntaxes, including ISO-compatible,
SQL-compatible,
- traditional
-
Postgres (see section on "relative time")
- and other permutations of time span. Output formats can be ISO-compatible,
-
SQL-compatible, or traditional
- with the default set to be
Postgres-compatible.
- Months and years are a "qualitative" time interval, and are stored separately
- from the other "quantitative" time intervals such as day or hour.
- For date arithmetic,
- the qualitative time units are instantiated in the context of the
- relevant date or time.
+ interval output looks like the input format, expect that units like
+ week or century are converted to years and days.
+ In ISO mode the output looks like
+[ Quantity Units [ ... ] ] [ Days ] Hours:Minutes [ ago ]
+
- Time span is specified with the following syntax:
+ There are several ways to affect the appearance of date/time types:
- Quantity Unit [Quantity Unit...] [Direction]
-@ Quantity Unit [Direction]
-where
- Quantity is ..., -1, 0, 1, 2, ...
- Unit is second, minute, hour, day, week, month, year,
- decade, century, millenium, or abbreviations or plurals of these units.
- Direction is ago.
-
+
+
+ The PGDATESTYLE environment variable used by the backend directly
+ on postmaster startup.
+
+
+
+ The PGDATESTYLE environment variable used by the frontend libpq
+ on session startup.
+
+
+
+
SET DATESTYLE SQL command.
+
+
+
+
-
<type>abstime</type>
-
- Absolute time (abstime) is a limited-range (+/- 68 years) and
- limited-precision (1 sec)
- date data type. datetime may be preferred, since it
- covers a larger range with greater precision.
-
+
Time Zones
- Absolute time is specified using the following syntax:
+
PostgreSQL endeavors to be compatible with
+
SQL92 definitions for typical usage.
+ However, the
SQL92 standard has an odd mix of date and
+ time types and capabilities. Two obvious problems are:
-Month Day [ Hour : Minute : Second ] Year [ Timezone ]
-where
- Month is Jan, Feb, ..., Dec
- Day is 1, 2, ..., 31
- Hour is 01, 02, ..., 24
- Minute is 00, 01, ..., 59
- Second is 00, 01, ..., 59
- Year is 1901, 1902, ..., 2038
-
-
+
+
+ Although the date type
+ does not have an associated time zone, the
+ time type can or does.
+
+
- Valid dates are from Dec 13 20:45:53 1901 GMT
- to Jan 19 03:14:04 2038 GMT.
+
+ The default time zone is specified as a constant integer offset
+ from GMT/UTC.
+
+
-
-
Historical Note
- As of Version 3.0, times are no longer read and written
- using Greenwich Mean Time; the input and output routines default to
- the local time zone.
-
+
- All special values allowed for datetime are also
- allowed for "absolute time".
+ Time zones in the real world can have no meaning unless
+ associated with a date as well as a time
+ since the offset may vary through the year with daylight savings
+ time boundaries.
-
-
-
-
<type>reltime</type>
+ To address these difficulties,
PostgreSQL + associates time zones only with date and time
+ types which contain both date and time,
+ and assumes local time for any type containing only
+ date or time. Further, time zone support is derived from
+ the underlying operating system
+ time zone capabilities, and hence can handle daylight savings time
+ and other expected behavior.
+
- Relative time reltime is a limited-range (+/- 68 years)
- and limited-precision (1 sec) time span data type.
- timespan should be preferred, since it
- covers a larger range with greater precision and, more importantly,
- can distinguish between
- relative units (months and years) and quantitative units (days, hours, etc).
- Instead, reltime
- must force months to be exactly 30 days, so time arithmetic does not
- always work as expected.
- For example, adding one reltime year to
- abstime today does not
- produce today's date one year from
- now, but rather a date 360 days from today.
+
PostgreSQL obtains time zone support
+ from the underlying operating system for dates between 1902 and
+ 2038 (near the typical date limits for Unix-style
+ systems). Outside of this range, all dates are assumed to be
+ specified and used in Universal Coordinated Time (UTC).
- reltime shares input and output routines with the other
- time span types.
- The section on timespan covers this in more detail.
+ All dates and times are stored internally in Universal UTC,
+ alternately known as Greenwich Mean Time (GMT).
+ Times are converted to local time on the database server before being
+ sent to the client frontend, hence by default are in the server
+ time zone.
-
+ There are several ways to affect the time zone behavior:
-
-
<type>timestamp</type>
+
+
+ The TZ environment variable used by the backend directly
+ on postmaster startup as the default time zone.
+
+
+
+ The PGTZ environment variable set at the client used by libpq
+ to send time zone information to the backend upon connection.
+
+
+
+ The
SQL command
SET TIME ZONE+ sets the time zone for the session.
+
+
+
+
- This is currently a limited-range absolute time which closely resembles the
- abstime
- data type. It shares the general input parser with the other date/time types.
- In future releases this type will absorb the capabilities of the
- datetime type
- and will move toward
SQL92 compliance.
+ If an invalid time zone is specified,
+ the time zone becomes GMT (on most systems anyway).
- timestamp is specified using the same syntax as for
- datetime.
+
+
+ If the compiler option USE_AUSTRALIAN_RULES is set
+ then EST refers to Australia Eastern Std Time,
+ which has an offset of +10:00 hours from UTC.
+
+
+
-
<span class="marked"><type>interval</type></span>
+
<span class="marked">Internals</span>
-
interval is an
SQL92 data type which is
- currently mapped to the timespan
+
PostgreSQL uses Julian dates
+ for all date/time calculations. They have the nice property of correctly
+ predicting/calculating any date more recent than 4713BC
+ to far into the future, using the assumption that the length of the
+ year is 365.2425 days.
-
-
-
-
<type>tinterval</type>
- Time ranges are specified as:
-
-[ 'abstime' 'abstime']
-where
- abstime is a time in the absolute time format.
-
-
- Special abstime values such as
- current, infinity and
- -infinity can be used.
+ Date conventions before the 19th century make for interesting reading,
+ but are not consistant enough to warrant coding into a date/time handler.
and make choices about what gets installed. Change into the src
subdirectory and type:
-$ ./configure [ options ]
+$ ./configure
+followed by any options you might want to give it. For a first installation
+you should be able to do fine without any.
For a complete list of options, type:
- ./configure --help
+./configure --help
Some of the more commonly used ones are:
The option specifies the location where the data will be
stored. You can use any path you want, it does not have to be under
the installation directory. Just make sure that the superuser account
-can write to it (or create it) before starting initdb.
+can write to the directory (or create it) before starting initdb.
+(If you have already been doing the installation up to now as the
PostgreSQL+superuser, you may have to log in as root temporarily to create the data directory.)
The previous step should have told you how to start up the database server.
Do so now.
-$ /usr/local/pgsql/initdb/postmaster -D /usr/local/pgsql/data
+$ /usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data
This will start the server in the foreground. To make it detach to
the background, use the .
$ cd /usr/src/pgsql/postgresql-7.0/doc
$ gmake install
-This will install files under /usr/local/pgsql/doc.
+This will install files under /usr/local/pgsql/doc
+and /usr/local/pgsql/man. To enable your system
+to find the
man documentation, you need to
+add a line like the following to a shell startup file:
+MANPATH=$MANPATH:/usr/local/pgsql/man
+
*
*
* IDENTIFICATION
- * $Header: /cvsroot/pgsql/src/backend/parser/scan.l,v 1.61 2000/01/20 05:26:53 tgl Exp $
+ * $Header: /cvsroot/pgsql/src/backend/parser/scan.l,v 1.62 2000/01/23 01:27:35 petere Exp $
*
*-------------------------------------------------------------------------
*/
isupper(yytext[i]))
yytext[i] = tolower(yytext[i]);
if (i >= NAMEDATALEN)
+ {
+ elog(NOTICE, "identifier \"%s\" will be truncated to \"%.*s\"",
+ yytext, NAMEDATALEN-1, yytext);
yytext[NAMEDATALEN-1] = '\0';
-
+ }
keyword = ScanKeywordLookup((char*)yytext);
if (keyword != NULL) {
return keyword->value;
*
* Copyright 2000 by PostgreSQL Global Development Team
*
- * $Header: /cvsroot/pgsql/src/bin/psql/command.c,v 1.14 2000/01/22 14:20:51 petere Exp $
+ * $Header: /cvsroot/pgsql/src/bin/psql/command.c,v 1.15 2000/01/23 01:27:37 petere Exp $
*/
#include
#include "command.h"
{
FILE *fd;
int result;
+ char *oldfilename;
if (!filename)
return false;
return false;
}
+ oldfilename = pset.inputfile;
pset.inputfile = filename;
result = MainLoop(fd);
fclose(fd);
- pset.inputfile = NULL;
+ pset.inputfile = oldfilename;
return (result == EXIT_SUCCESS);
}
*
*
* IDENTIFICATION
- * $Header: /cvsroot/pgsql/src/interfaces/libpq/fe-connect.c,v 1.113 2000/01/18 19:05:31 momjian Exp $
+ * $Header: /cvsroot/pgsql/src/interfaces/libpq/fe-connect.c,v 1.114 2000/01/23 01:27:39 petere Exp $
*
*-------------------------------------------------------------------------
*/
else
conn->dbName = strdup(dbName);
- if (conn->dbName)
- {
-
- /*
- * if the database name is surrounded by double-quotes, then don't
- * convert case
- */
- if (*conn->dbName == '"')
- {
- strcpy(conn->dbName, conn->dbName + 1);
- conn->dbName[strlen(conn->dbName) - 1] = '\0';
- }
- else
- for (i = 0; conn->dbName[i]; i++)
- if (isascii((unsigned char) conn->dbName[i]) &&
- isupper(conn->dbName[i]))
- conn->dbName[i] = tolower(conn->dbName[i]);
- }
-
if (error)
{
conn->status = CONNECTION_BAD;
projects / postgresql.git / commitdiff