rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Add chapters on CVS access, MVCC, SQL theory to the docs. 

Add an appendix with more details on date/time attributes and handling.
Update most references to Postgres version numbers to 6.5,
 *except* for the porting list which will require a report
 from a successful installation to be updated.
This commit is contained in:
Thomas G. Lockhart 1999-05-26 17:30:30 +00:00
parent 0807dbb294
commit 9474dd7ed6
13 changed files with 774 additions and 1155 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
doc/src/sgml/admin.sgml
View File

@ -1,11 +1,18 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/admin.sgml,v 1.13 1999/05/20 05:39:25 thomas Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/admin.sgml,v 1.14 1999/05/26 17:30:27 thomas Exp $
Postgres Administrator's Guide.
Derived from postgres.sgml.
- thomas 1998-10-27
$Log: admin.sgml,v $
Revision 1.14 1999/05/26 17:30:27 thomas
Add chapters on CVS access, MVCC, SQL theory to the docs.
Add an appendix with more details on date/time attributes and handling.
Update most references to Postgres version numbers to 6.5,
*except* for the porting list which will require a report
from a successful installation to be updated.
Revision 1.13 1999/05/20 05:39:25 thomas
Rearrange and consolidate the Admin Guide.
Add reference pages for utilities and remove standalone chapters for same.
@ -73,7 +80,7 @@ Bigger updates to the installation instructions (install and config).
<Title>PostgreSQL Administrator's Guide</Title>
<BookInfo>
<ReleaseInfo>Covering v6.4 for general release</ReleaseInfo>
<ReleaseInfo>Covering v6.5 for general release</ReleaseInfo>
<BookBiblio>
<AuthorGroup>
<CorpAuthor>The PostgreSQL Development Team</CorpAuthor>
@ -96,12 +103,12 @@ Bigger updates to the installation instructions (install and config).
<AuthorInitials>TGL</AuthorInitials>
-->
<Date>(last updated 1999-05-19)</Date>
<Date>(last updated 1999-06-01)</Date>
</BookBiblio>
<LegalNotice>
<Para>
<ProductName>PostgreSQL</ProductName> is copyright (&copy;) 1998-9
<ProductName>PostgreSQL</ProductName> is &copy; 1998-9
by the Postgres Global Development Group.
</Para>
</LegalNotice>

65
doc/src/sgml/biblio.sgml
View File

@ -98,6 +98,39 @@
<!--
<BIBLIOMISC>&dash;</BIBLIOMISC>
<BOOKBIBLIO ID="DATE94">
-->
<title id="DATE94-full">
An Introduction to Database Systems
</title>
<titleabbrev id="DATE94">
Date, 1994
</titleabbrev>
<edition>6</edition>
<authorgroup>
<author>
<firstname>C. J.</firstname>
<surname>Date</surname>
</author>
</authorgroup>
<volumenum>1</volumenum>
<pubdate>1994</pubdate>
<publisher>
<publishername>Addison-Wesley</publishername>
</publisher>
<copyright>
<year>1994</year>
<holder>Addison-Wesley Longman, Inc.</holder>
</copyright>
<!--
</BOOKBIBLIO>
-->
</biblioentry>
<biblioentry>
<!--
<BIBLIOMISC>&dash;</BIBLIOMISC>
<BOOKBIBLIO ID="MELT93">
-->
<title id="MELT93-full">
@ -135,6 +168,38 @@
-->
</biblioentry>
<biblioentry>
<!--
<BIBLIOMISC>&dash;</BIBLIOMISC>
<BOOKBIBLIO ID="ULL88">
-->
<title id="ULL88-full">
Principles of Database and Knowledge
</title>
<subtitle>
Base Systems
</subtitle>
<titleabbrev id="ULL88">
Ullman, 1988
</titleabbrev>
<authorgroup>
<author>
<firstname>Jeffrey D.</firstname>
<surname>Ullman</surname>
</author>
</authorgroup>
<volumenum>1</volumenum>
<publisher>
<publishername>
Computer Science Press
</publishername>
</publisher>
<pubdate>
1988
</pubdate>
</biblioentry>
</bibliodiv>
<bibliodiv>

17
doc/src/sgml/cvs.sgml
View File

@ -1,9 +1,16 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/cvs.sgml,v 1.5 1999/05/22 02:27:23 thomas Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/cvs.sgml,v 1.6 1999/05/26 17:30:28 thomas Exp $
CVS code repository
Thomas Lockhart
$Log: cvs.sgml,v $
Revision 1.6 1999/05/26 17:30:28 thomas
Add chapters on CVS access, MVCC, SQL theory to the docs.
Add an appendix with more details on date/time attributes and handling.
Update most references to Postgres version numbers to 6.5,
*except* for the porting list which will require a report
from a successful installation to be updated.
Revision 1.5 1999/05/22 02:27:23 thomas
Finish initial markup of cvs.sgml, and include it in the programmer's guide
and the integrated doc. Clean up other markup.
@ -52,7 +59,7 @@ Not yet included in a document (should go in the developer's doc?).
</para>
<para>
At least two options,
At least two methods,
anonymous CVS and <productname>CVSup</productname>,
are available to pull the <productname>CVS</productname> code tree from the
<productname>Postgres</productname> server to your local machine.
@ -496,7 +503,7 @@ pgsql
<title><productname>CVSup</productname> Installation from Binaries</title>
<para>
You can instead use pre-built binaries
You can use pre-built binaries
if you have a platform for which binaries
are posted on
<ulink url="ftp://postgresql.org/pub">the <productname>Postgres</productname> ftp site</ulink>,
@ -517,7 +524,7 @@ pgsql
<para>
At the time of writing, binaries are available for
Alpha/Tru64, ix86/xBSD,
HPPA/HPUX-10.20, and MIPS/irix.
HPPA/HPUX-10.20, MIPS/irix,
ix86/linux-libc5, ix86/linux-glibc,
Sparc/Solaris, and Sparc/SunOS.
</para>
@ -540,7 +547,7 @@ pgsql
<step performance="optional">
<para>
If you have another platform, check for and download the appropriate binary from
<ulink url="ftp://postgresql.org/pub">the <productname>Postgres</productname> ftp site</ulink>,
<ulink url="ftp://postgresql.org/pub">the <productname>Postgres</productname> ftp site</ulink>.
</para>
</step>
</substeps>

567
doc/src/sgml/datatype.sgml
View File

@ -842,15 +842,15 @@ on session startup.
</itemizedlist>
</para>
<para>
For <productname>Postgres</productname> v6.4 (and earlier)
the default date/time style is
"non-European traditional Postgres".
In future releases, the default may become "ISO" (compatible with ISO-8601),
which alleviates date specification ambiguities and Y2K collation problems.
</para>
<para>
For <productname>Postgres</productname> v6.4 (and earlier)
the default date/time style is
"non-European traditional Postgres".
In future releases, the default may become "ISO" (compatible with ISO-8601),
which alleviates date specification ambiguities and Y2K collation problems.
</para>
</sect2>
</sect2>
<sect2>
<title>Calendar</title>
@ -858,7 +858,7 @@ which alleviates date specification ambiguities and Y2K collation problems.
<para>
<productname>Postgres</productname> uses Julian dates
for all date/time calculations. They have the nice property of correctly
predicting/calculating any date more recent than something like 4013BC
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.
</para>
@ -1279,391 +1279,9 @@ which alleviates date specification ambiguities and Y2K collation problems.
</para>
<para>
<table tocentry="1">
<title><productname>Postgres</productname> Recognized Time Zones</title>
<titleabbrev>Time Zones</titleabbrev>
<tgroup cols="3">
<thead>
<row>
<entry>Time Zone</entry>
<entry>Offset from UTC</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry>NZDT</entry>
<entry>+13:00</entry>
<entry>New Zealand Daylight Time</entry>
</row>
<row>
<entry>IDLE</entry>
<entry>+12:00</entry>
<entry>International Date Line, East</entry>
</row>
<row>
<entry>NZST</entry>
<entry>+12:00</entry>
<entry>New Zealand Std Time</entry>
</row>
<row>
<entry>NZT</entry>
<entry>+12:00</entry>
<entry>New Zealand Time</entry>
</row>
<row>
<entry>AESST</entry>
<entry>+11:00 </entry>
<entry>Australia Eastern Summer Std Time</entry>
</row>
<row>
<entry>ACSST</entry>
<entry>+10:30 </entry>
<entry>Central Australia Summer Std Time</entry>
</row>
<row>
<entry>CADT</entry>
<entry>+10:30 </entry>
<entry>Central Australia Daylight Savings Time</entry>
</row>
<row>
<entry>SADT</entry>
<entry>+10:30</entry>
<entry>South Australian Daylight Time</entry>
</row>
<row>
<entry>AEST</entry>
<entry>+10:00 </entry>
<entry>Australia Eastern Std Time</entry>
</row>
<row>
<entry>EAST</entry>
<entry>+10:00 </entry>
<entry>East Australian Std Time</entry>
</row>
<row>
<entry>GST</entry>
<entry>+10:00</entry>
<entry>Guam Std Time, USSR Zone 9</entry>
</row>
<row>
<entry>LIGT</entry>
<entry>+10:00</entry>
<entry>Melbourne, Australia</entry>
</row>
<row>
<entry>ACST</entry>
<entry>+09:30 </entry>
<entry>Central Australia Std Time</entry>
</row>
<row>
<entry>CAST</entry>
<entry>+09:30 </entry>
<entry>Central Australia Std Time</entry>
</row>
<row>
<entry>SAT</entry>
<entry>+9:30</entry>
<entry>South Australian Std Time</entry>
</row>
<row>
<entry>AWSST</entry>
<entry>+9:00 </entry>
<entry>Australia Western Summer Std Time</entry>
</row>
<row>
<entry>JST</entry>
<entry>+9:00</entry>
<entry>Japan Std Time,USSR Zone 8</entry>
</row>
<row>
<entry>KST</entry>
<entry>+9:00</entry>
<entry>Korea Standard Time</entry>
</row>
<row>
<entry>WDT</entry>
<entry>+9:00</entry>
<entry>West Australian Daylight Time</entry>
</row>
<row>
<entry>MT</entry>
<entry>+8:30</entry>
<entry>Moluccas Time</entry>
</row>
<row>
<entry>AWST</entry>
<entry>+8:00 </entry>
<entry>Australia Western Std Time</entry>
</row>
<row>
<entry>CCT</entry>
<entry>+8:00 </entry>
<entry>China Coastal Time</entry>
</row>
<row>
<entry>WADT</entry>
<entry>+8:00</entry>
<entry>West Australian Daylight Time</entry>
</row>
<row>
<entry>WST</entry>
<entry>+8:00</entry>
<entry>West Australian Std Time</entry>
</row>
<row>
<entry>JT</entry>
<entry>+7:30</entry>
<entry>Java Time</entry>
</row>
<row>
<entry>WAST</entry>
<entry>+7:00</entry>
<entry>West Australian Std Time</entry>
</row>
<row>
<entry>IT</entry>
<entry>+3:30</entry>
<entry>Iran Time</entry>
</row>
<row>
<entry>BT</entry>
<entry>+3:00 </entry>
<entry>Baghdad Time</entry>
</row>
<row>
<entry>EETDST</entry>
<entry>+3:00 </entry>
<entry>Eastern Europe Daylight Savings Time</entry>
</row>
<row>
<entry>CETDST</entry>
<entry>+2:00 </entry>
<entry>Central European Daylight Savings Time</entry>
</row>
<row>
<entry>EET</entry>
<entry>+2:00 </entry>
<entry>Eastern Europe, USSR Zone 1</entry>
</row>
<row>
<entry>FWT</entry>
<entry>+2:00</entry>
<entry>French Winter Time</entry>
</row>
<row>
<entry>IST</entry>
<entry>+2:00</entry>
<entry>Israel Std Time</entry>
</row>
<row>
<entry>MEST</entry>
<entry>+2:00</entry>
<entry>Middle Europe Summer Time</entry>
</row>
<row>
<entry>METDST</entry>
<entry>+2:00</entry>
<entry>Middle Europe Daylight Time</entry>
</row>
<row>
<entry>SST</entry>
<entry>+2:00</entry>
<entry>Swedish Summer Time</entry>
</row>
<row>
<entry>BST</entry>
<entry>+1:00 </entry>
<entry>British Summer Time</entry>
</row>
<row>
<entry>CET</entry>
<entry>+1:00 </entry>
<entry>Central European Time</entry>
</row>
<row>
<entry>DNT</entry>
<entry>+1:00 </entry>
<entry>Dansk Normal Tid</entry>
</row>
<row>
<entry>DST</entry>
<entry>+1:00 </entry>
<entry>Dansk Standard Time (?)</entry>
</row>
<row>
<entry>FST</entry>
<entry>+1:00 </entry>
<entry>French Summer Time</entry>
</row>
<row>
<entry>MET</entry>
<entry>+1:00</entry>
<entry>Middle Europe Time</entry>
</row>
<row>
<entry>MEWT</entry>
<entry>+1:00</entry>
<entry>Middle Europe Winter Time</entry>
</row>
<row>
<entry>MEZ</entry>
<entry>+1:00</entry>
<entry>Middle Europe Zone</entry>
</row>
<row>
<entry>NOR</entry>
<entry>+1:00</entry>
<entry>Norway Standard Time</entry>
</row>
<row>
<entry>SET</entry>
<entry>+1:00</entry>
<entry>Seychelles Time</entry>
</row>
<row>
<entry>SWT</entry>
<entry>+1:00</entry>
<entry>Swedish Winter Time</entry>
</row>
<row>
<entry>WETDST</entry>
<entry>+1:00</entry>
<entry>Western Europe Daylight Savings Time</entry>
</row>
<row>
<entry>GMT</entry>
<entry>0:00</entry>
<entry>Greenwish Mean Time</entry>
</row>
<row>
<entry>WET</entry>
<entry>0:00</entry>
<entry>Western Europe</entry>
</row>
<row>
<entry>WAT</entry>
<entry>-1:00</entry>
<entry>West Africa Time</entry>
</row>
<row>
<entry>NDT</entry>
<entry>-2:30</entry>
<entry>Newfoundland Daylight Time</entry>
</row>
<row>
<entry>ADT</entry>
<entry>-03:00 </entry>
<entry>Atlantic Daylight Time</entry>
</row>
<row>
<entry>NFT</entry>
<entry>-3:30</entry>
<entry>Newfoundland Standard Time</entry>
</row>
<row>
<entry>NST</entry>
<entry>-3:30</entry>
<entry>Newfoundland Standard Time</entry>
</row>
<row>
<entry>AST</entry>
<entry>-4:00 </entry>
<entry>Atlantic Std Time (Canada)</entry>
</row>
<row>
<entry>EDT</entry>
<entry>-4:00 </entry>
<entry>Eastern Daylight Time</entry>
</row>
<row>
<entry>ZP4</entry>
<entry>-4:00</entry>
<entry>GMT +4 hours</entry>
</row>
<row>
<entry>CDT</entry>
<entry>-5:00 </entry>
<entry>Central Daylight Time</entry>
</row>
<row>
<entry>EST</entry>
<entry>-5:00 </entry>
<entry>Eastern Standard Time</entry>
</row>
<row>
<entry>ZP5</entry>
<entry>-5:00</entry>
<entry>GMT +5 hours</entry>
</row>
<row>
<entry>CST</entry>
<entry>-6:00 </entry>
<entry>Central Std Time</entry>
</row>
<row>
<entry>MDT</entry>
<entry>-6:00</entry>
<entry>Mountain Daylight Time</entry>
</row>
<row>
<entry>ZP6</entry>
<entry>-6:00</entry>
<entry>GMT +6 hours</entry>
</row>
<row>
<entry>MST</entry>
<entry>-7:00</entry>
<entry>Mountain Standard Time</entry>
</row>
<row>
<entry>PDT</entry>
<entry>-7:00</entry>
<entry>Pacific Daylight Time</entry>
</row>
<row>
<entry>PST</entry>
<entry>-8:00</entry>
<entry>Pacific Std Time</entry>
</row>
<row>
<entry>YDT</entry>
<entry>-8:00</entry>
<entry>Yukon Daylight Time</entry>
</row>
<row>
<entry>HDT</entry>
<entry>-9:00</entry>
<entry>Hawaii/Alaska Daylight Time</entry>
</row>
<row>
<entry>YST</entry>
<entry>-9:00</entry>
<entry>Yukon Standard Time</entry>
</row>
<row>
<entry>AHST</entry>
<entry>-10:00 </entry>
<entry>Alaska-Hawaii Std Time</entry>
</row>
<row>
<entry>CAT</entry>
<entry>-10:00 </entry>
<entry>Central Alaska Time</entry>
</row>
<row>
<entry>NT</entry>
<entry>-11:00</entry>
<entry>Nome Time</entry>
</row>
<row>
<entry>IDLW</entry>
<entry>-12:00</entry>
<entry>International Date Line, West</entry>
</row>
</tbody>
</tgroup>
</table>
See <xref linkend="datetime-appendix-title" endterm="datetime-appendix-title">
for details on time zones recognized by <productname>Postgres</productname>.
<note>
<para>
If the compiler option USE_AUSTRALIAN_RULES is set
@ -1671,7 +1289,7 @@ which alleviates date specification ambiguities and Y2K collation problems.
which has an offset of +10:00 hours from UTC.
</para>
</note>
</para>
</para>
<para>
Australian time zones and their naming variants
@ -1679,165 +1297,6 @@ which alleviates date specification ambiguities and Y2K collation problems.
<productname>Postgres</productname> time zone lookup table.
</para>
<procedure>
<title>Date/Time Input Interpretation</title>
<para>
The date/time types are all decoded using a common set of routines.
</para>
<step>
<para>
Break the input string into tokens and categorize each token as
a string, time, time zone, or number.
</para>
<substeps>
<step>
<para>
If the token contains a colon (":"), this is a time string.
</para>
</step>
<step>
<para>
If the token contains a dash ("-"), slash ("/"), or dot ("."),
this is a date string which may have a text month.
</para>
</step>
<step>
<para>
If the token is numeric only, then it is either a single field
or an ISO-8601 concatenated date (e.g. "19990113" for January 13, 1999)
or time (e.g. 141516 for 14:15:16).
</para>
</step>
<step>
<para>
If the token starts with a plus ("+") or minus ("-"),
then it is either a time zone or a special field.
</para>
</step>
</substeps>
</step>
<step>
<para>
If the token is a text string, match up with possible strings.
</para>
<substeps>
<step>
<para>
Do a binary-search table lookup for the token
as either a special string (e.g. <literal>today</literal>),
day (e.g. <literal>Thursday</literal>),
month (e.g. <literal>January</literal>), or noise word (e.g. <literal>on</literal>).
</para>
<para>
Set field values and bit mask for fields.
For example, set year, month, day for <literal>today</literal>, and additionally
hour, minute, second for <literal>now</literal>.
</para>
</step>
<step>
<para>
If not found, do a similar binary-search table lookup to match
the token with a time zone.
</para>
</step>
<step>
<para>
If not found, throw an error.
</para>
</step>
</substeps>
</step>
<step>
<para>
The token is a number or number field.
If there are more than 4 digits,
and if no other date fields have been previously read, then interpret
as a "concatenated date" (e.g. <literal>19990118</literal>).
</para>
<substeps>
<step>
<para>
If there are more than 4 digits,
and if no other date fields have been previously read, then interpret
as a "concatenated date" (e.g. <literal>19990118</literal>).
</para>
</step>
<step>
<para>
If three digits and a year has already been decoded, then interpret as day of year.
</para>
</step>
<step>
<para>
If longer than two digits, then interpret as a year.
</para>
</step>
<step>
<para>
If in European date mode, and if the day field has not yet been read,
and if the value is less than or equal to 31, then interpret as a day.
</para>
</step>
<step>
<para>
If in non-European (US) date mode, and if the month field has not yet been read,
and if the value is less than or equal to 12, then interpret as a month.
</para>
</step>
<step>
<para>
If the day field has not yet been read,
and if the value is less than or equal to 31, then interpret as a month.
</para>
</step>
<step>
<para>
If the month field has not yet been read,
and if the value is less than or equal to 12, then interpret as a month.
</para>
</step>
<step>
<para>
Otherwise, interpret as a year.
</para>
</step>
</substeps>
</step>
<step>
<para>
If BC has been specified, negate the year and offset by one
(there is no year zero in the Gregorian calendar).
</para>
</step>
<step>
<para>
If BC was not specified, and if the year field was two digits in length, then
adjust the year to 4 digits. If the field was less than 70, then add 2000;
otherwise, add 1900.
</para>
</step>
</procedure>
</sect2>
<sect2>

13
doc/src/sgml/datetime.sgml
View File

@ -1,16 +1,23 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/datetime.sgml,v 2.2 1999/05/22 02:27:23 thomas Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/datetime.sgml,v 2.3 1999/05/26 17:30:28 thomas Exp $
Date/time details
$Log: datetime.sgml,v $
Revision 2.3 1999/05/26 17:30:28 thomas
Add chapters on CVS access, MVCC, SQL theory to the docs.
Add an appendix with more details on date/time attributes and handling.
Update most references to Postgres version numbers to 6.5,
*except* for the porting list which will require a report
from a successful installation to be updated.
Revision 2.2 1999/05/22 02:27:23 thomas
Finish initial markup of cvs.sgml, and include it in the programmer's guide
and the integrated doc. Clean up other markup.
-->
<appendix label="UG1" id="datetime-append">
<title>Date/Time Support</title>
<appendix label="UG1" id="datetime-appendix">
<title id="datetime-appendix-title">Date/Time Support</title>
<sect1>
<title>Time Zones</title>

15
doc/src/sgml/installation.sgml
View File

@ -1,10 +1,17 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/installation.sgml,v 1.3 1998/11/02 15:53:02 thomas Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/installation.sgml,v 1.4 1999/05/26 17:30:29 thomas Exp $
Postgres quick Installation Guide.
- thomas 1998-10-26
$Log: installation.sgml,v $
Revision 1.4 1999/05/26 17:30:29 thomas
Add chapters on CVS access, MVCC, SQL theory to the docs.
Add an appendix with more details on date/time attributes and handling.
Update most references to Postgres version numbers to 6.5,
*except* for the porting list which will require a report
from a successful installation to be updated.
Revision 1.3 1998/11/02 15:53:02 thomas
Move configuration info to after installation procedure.
Include only the current release in the release notes section.
@ -50,7 +57,7 @@ First cut at standalone installation guide to replace INSTALL text source.
<Title>PostgreSQL Installation Guide</Title>
<BookInfo>
<ReleaseInfo>Covering v6.4 for general release</ReleaseInfo>
<ReleaseInfo>Covering v6.5 for general release</ReleaseInfo>
<BookBiblio>
<AuthorGroup>
<CorpAuthor>The PostgreSQL Development Team</CorpAuthor>
@ -73,12 +80,12 @@ First cut at standalone installation guide to replace INSTALL text source.
<AuthorInitials>TGL</AuthorInitials>
-->
<Date>(last updated 1998-02-23)</Date>
<Date>(last updated 1999-06-01)</Date>
</BookBiblio>
<LegalNotice>
<Para>
<ProductName>PostgreSQL</ProductName> is copyright (C) 1998
<ProductName>PostgreSQL</ProductName> is &copy; 1998-9
by the Postgres Global Development Group.
</Para>
</LegalNotice>

626
doc/src/sgml/ports.sgml
View File

@ -1,327 +1,327 @@
<Chapter Id="ports">
<Title>Ports</Title>
<chapter id="ports">
<title>Ports</title>
<Para>
This manual describes version 6.5 of <ProductName>Postgres</ProductName>.
The <ProductName>Postgres</ProductName> developer community has
compiled and tested <ProductName>Postgres</ProductName> on a
number of platforms. Check
<ulink url="http://www.postgresql.org/docs/admin/ports.htm">the web site</ulink>
for the latest information.
</para>
<para>
This manual describes version 6.5 of <productname>Postgres</productname>.
The <productname>Postgres</productname> developer community has
compiled and tested <productname>Postgres</productname> on a
number of platforms. Check
<ulink url="http://www.postgresql.org/docs/admin/ports.htm">the web site</ulink>
for the latest information.
</para>
<Sect1>
<Title>Currently Supported Platforms</Title>
<sect1>
<title>Currently Supported Platforms</title>
<para>
At the time of publication, the following platforms have been tested:
<para>
At the time of publication, the following platforms have been tested:
<TABLE TOCENTRY="1">
<TITLE>Supported Platforms</TITLE>
<TGROUP COLS="4">
<THEAD>
<ROW>
<ENTRY><Acronym>OS</Acronym></ENTRY>
<ENTRY>Processor</ENTRY>
<ENTRY>Version</ENTRY>
<ENTRY>Reported</ENTRY>
<ENTRY>Remarks</ENTRY>
</ROW>
</THEAD>
<TBODY>
<ROW>
<ENTRY>AIX 4.2.1</ENTRY>
<ENTRY>RS6000</ENTRY>
<ENTRY>v6.4</ENTRY>
<ENTRY>1998-10-27</ENTRY>
<ENTRY>(<ULink url="mailto:Andreas.Zeugswetter@telecom.at">Andreas Zeugswetter</ULink>)</ENTRY>
</ROW>
<ROW>
<ENTRY>BSDI</ENTRY>
<ENTRY>x86</ENTRY>
<ENTRY>v6.4</ENTRY>
<ENTRY>1998-10-25</ENTRY>
<ENTRY>(<ULink url="mailto:maillist@candle.pha.pa.us">Bruce Momjian</ULink></ENTRY>
</ROW>
<ROW>
<ENTRY>FreeBSD 2.2.x-3.x</ENTRY>
<ENTRY>x86</ENTRY>
<ENTRY>v6.4</ENTRY>
<ENTRY>1998-10-26</ENTRY>
<ENTRY>(<ULink url="mailto:t-ishii@sra.co.jp">Tatsuo Ishii</ULink>,
<ULink url="mailto:scrappy@hub.org">Marc Fournier</ULink>)</ENTRY>
</ROW>
<ROW>
<ENTRY>DGUX 5.4R4.11</ENTRY>
<ENTRY>m88k</ENTRY>
<ENTRY>v6.3</ENTRY>
<ENTRY>1998-03-01</ENTRY>
<ENTRY>v6.4 probably OK. Needs new maintainer.
(<ULink url="mailto:geek+@cmu.edu">Brian E Gallew</ULink>)</ENTRY>
</ROW>
<ROW>
<ENTRY>Digital Unix 4.0</ENTRY>
<ENTRY>Alpha</ENTRY>
<ENTRY>v6.4</ENTRY>
<ENTRY>1998-10-29</ENTRY>
<ENTRY>Minor patchable problems
(<ULink url="mailto:pjlobo@euitt.upm.es">Pedro J. Lobo</ULink>)</ENTRY>
</ROW>
<ROW>
<ENTRY>HPUX</ENTRY>
<ENTRY>PA-RISC</ENTRY>
<ENTRY>v6.4</ENTRY>
<ENTRY>1998-10-25</ENTRY>
<ENTRY>Both 9.0x and 10.20
(<ULink url="mailto:tgl@sss.pgh.pa.us">Tom Lane</ULink>,
<ULink url="mailto:stanb@awod.com">Stan Brown</ULink>)</ENTRY>
</ROW>
<ROW>
<ENTRY>IRIX 6.5</ENTRY>
<ENTRY>MIPS</ENTRY>
<ENTRY>v6.4</ENTRY>
<ENTRY>1998-12-29</ENTRY>
<ENTRY>IRIX 5.x is different
(<ULink url="mdalphin@amgen.com">Mark Dalphin</ULink>)</ENTRY>
</ROW>
<ROW>
<ENTRY>linux 2.0.x</ENTRY>
<ENTRY>Alpha</ENTRY>
<ENTRY>v6.3.2</ENTRY>
<ENTRY>1998-04-16</ENTRY>
<ENTRY>Mostly successful. Needs work for v6.4.
(<ULink url="mailto:rkirkpat@nag.cs.colorado.edu">Ryan Kirkpatrick</ULink>)</ENTRY>
</ROW>
<ROW>
<ENTRY>linux 2.0.x/libc5</ENTRY>
<ENTRY>x86</ENTRY>
<ENTRY>v6.4</ENTRY>
<ENTRY>1998-10-27</ENTRY>
<ENTRY>(<ULink url="mailto:lockhart@alumni.caltech.edu">Thomas Lockhart</ULink>)</ENTRY>
</ROW>
<ROW>
<ENTRY>linux 2.0.x/glibc2</ENTRY>
<ENTRY>x86</ENTRY>
<ENTRY>v6.4</ENTRY>
<ENTRY>1998-10-25</ENTRY>
<ENTRY>(<ulink url="mailto:olly@lfix.co.uk">Oliver Elphick</ulink>,
<ulink url="mailto:taral@mail.utexas.edu">Taral</ulink>)</ENTRY>
</ROW>
<ROW>
<ENTRY>linux 2.0.x</ENTRY>
<ENTRY>MIPS</ENTRY>
<ENTRY>v6.4</ENTRY>
<ENTRY>1998-12-16</ENTRY>
<ENTRY>Cobalt Qube
(<ULink url="mailto:t-ishii@sra.co.jp">Tatsuo Ishii</ULink>)</ENTRY>
</ROW>
<ROW>
<ENTRY>linux 2.0.x</ENTRY>
<ENTRY>Sparc</ENTRY>
<ENTRY>v6.4</ENTRY>
<ENTRY>1998-10-25</ENTRY>
<ENTRY>(<ULink url="mailto:szybist@boxhill.com">Tom Szybist</ULink>)</ENTRY>
</ROW>
<ROW>
<ENTRY>linuxPPC 2.1.24</ENTRY>
<ENTRY>PPC603e</ENTRY>
<ENTRY>v6.4</ENTRY>
<ENTRY>1998-10-26</ENTRY>
<ENTRY>Powerbook 2400c
(<ULink url="mailto:t-ishii@sra.co.jp">Tatsuo Ishii</ULink>)</ENTRY>
</ROW>
<ROW>
<ENTRY>mklinux DR3</ENTRY>
<ENTRY>PPC750</ENTRY>
<ENTRY>v6.4</ENTRY>
<ENTRY>1998-09-16</ENTRY>
<ENTRY>PowerMac 7600
(<ULink url="mailto:t-ishii@sra.co.jp">Tatsuo Ishii</ULink>)</ENTRY>
</ROW>
<ROW>
<ENTRY>NetBSD/i386 1.3.2</ENTRY>
<ENTRY>x86</ENTRY>
<ENTRY>v6.4</ENTRY>
<ENTRY>1998-10-25</ENTRY>
<ENTRY>(<ULink url="mailto:brook@trillium.NMSU.Edu">Brook Milligan</ULink>)</ENTRY>
</ROW>
<ROW>
<ENTRY>NetBSD</ENTRY>
<ENTRY>m68k</ENTRY>
<ENTRY>v6.4.2</ENTRY>
<ENTRY>1998-12-28</ENTRY>
<ENTRY>Mac SE/30
<table tocentry="1">
<title>Supported Platforms</title>
<tgroup cols="4">
<thead>
<row>
<entry><acronym>OS</acronym></entry>
<entry>Processor</entry>
<entry>Version</entry>
<entry>Reported</entry>
<entry>Remarks</entry>
</row>
</thead>
<tbody>
<row>
<entry>AIX 4.2.1</entry>
<entry>RS6000</entry>
<entry>v6.4</entry>
<entry>1998-10-27</entry>
<entry>(<ulink url="mailto:Andreas.Zeugswetter@telecom.at">Andreas Zeugswetter</ulink>)</entry>
</row>
<row>
<entry>BSDI</entry>
<entry>x86</entry>
<entry>v6.5</entry>
<entry>1999-05-25</entry>
<entry>(<ulink url="mailto:maillist@candle.pha.pa.us">Bruce Momjian</ulink></entry>
</row>
<row>
<entry>FreeBSD 2.2.x-3.x</entry>
<entry>x86</entry>
<entry>v6.5</entry>
<entry>1999-05-25</entry>
<entry>(<ulink url="mailto:t-ishii@sra.co.jp">Tatsuo Ishii</ulink>,
<ulink url="mailto:scrappy@hub.org">Marc Fournier</ulink>)</entry>
</row>
<row>
<entry>DGUX 5.4R4.11</entry>
<entry>m88k</entry>
<entry>v6.3</entry>
<entry>1998-03-01</entry>
<entry>v6.4 probably OK. Needs new maintainer.
(<ulink url="mailto:geek+@cmu.edu">Brian E Gallew</ulink>)</entry>
</row>
<row>
<entry>Digital Unix 4.0</entry>
<entry>Alpha</entry>
<entry>v6.4</entry>
<entry>1998-10-29</entry>
<entry>Minor patchable problems
(<ulink url="mailto:pjlobo@euitt.upm.es">Pedro J. Lobo</ulink>)</entry>
</row>
<row>
<entry>HPUX</entry>
<entry>PA-RISC</entry>
<entry>v6.4</entry>
<entry>1998-10-25</entry>
<entry>Both 9.0x and 10.20
(<ulink url="mailto:tgl@sss.pgh.pa.us">Tom Lane</ulink>,
<ulink url="mailto:stanb@awod.com">Stan Brown</ulink>)</entry>
</row>
<row>
<entry>IRIX 6.5</entry>
<entry>MIPS</entry>
<entry>v6.4</entry>
<entry>1998-12-29</entry>
<entry>IRIX 5.x is different
(<ulink url="mdalphin@amgen.com">Mark Dalphin</ulink>)</entry>
</row>
<row>
<entry>linux 2.0.x</entry>
<entry>Alpha</entry>
<entry>v6.3.2</entry>
<entry>1998-04-16</entry>
<entry>Mostly successful. Needs work for v6.4.
(<ulink url="mailto:rkirkpat@nag.cs.colorado.edu">Ryan Kirkpatrick</ulink>)</entry>
</row>
<row>
<entry>linux 2.0.x/libc5</entry>
<entry>x86</entry>
<entry>v6.4</entry>
<entry>1998-10-27</entry>
<entry>(<ulink url="mailto:lockhart@alumni.caltech.edu">Thomas Lockhart</ulink>)</entry>
</row>
<row>
<entry>linux 2.0.x/glibc2</entry>
<entry>x86</entry>
<entry>v6.4</entry>
<entry>1999-05-24</entry>
<entry>(<ulink url="mailto:lockhart@alumni.caltech.edu">Thomas Lockhart</ulink>)</entry>
</row>
<row>
<entry>linux 2.0.x</entry>
<entry>MIPS</entry>
<entry>v6.4</entry>
<entry>1998-12-16</entry>
<entry>Cobalt Qube
(<ulink url="mailto:t-ishii@sra.co.jp">Tatsuo Ishii</ulink>)</entry>
</row>
<row>
<entry>linux 2.0.x</entry>
<entry>Sparc</entry>
<entry>v6.4</entry>
<entry>1998-10-25</entry>
<entry>(<ulink url="mailto:szybist@boxhill.com">Tom Szybist</ulink>)</entry>
</row>
<row>
<entry>linuxPPC 2.1.24</entry>
<entry>PPC603e</entry>
<entry>v6.4</entry>
<entry>1998-10-26</entry>
<entry>Powerbook 2400c
(<ulink url="mailto:t-ishii@sra.co.jp">Tatsuo Ishii</ulink>)</entry>
</row>
<row>
<entry>mklinux DR3</entry>
<entry>PPC750</entry>
<entry>v6.4</entry>
<entry>1998-09-16</entry>
<entry>PowerMac 7600
(<ulink url="mailto:t-ishii@sra.co.jp">Tatsuo Ishii</ulink>)</entry>
</row>
<row>
<entry>NetBSD</entry>
<entry>arm32</entry>
<entry>v6.5</entry>
<entry>1999-04-14</entry>
<entry>(<ulink url="mailto:a.mcmurry1@physics.oxford.ac.uk">Andrew McMurry</ulink>)</entry>
</row>
<row>
<entry>NetBSD/i386 1.3.2</entry>
<entry>x86</entry>
<entry>v6.4</entry>
<entry>1998-10-25</entry>
<entry>(<ulink url="mailto:brook@trillium.NMSU.Edu">Brook Milligan</ulink>)</entry>
</row>
<row>
<entry>NetBSD</entry>
<entry>m68k</entry>
<entry>v6.4.2</entry>
<entry>1998-12-28</entry>
<entry>Mac SE/30
(Mr. Mutsuki Nakajima,
<ULink url="mailto:t-ishii@sra.co.jp">Tatsuo Ishii</ULink>)</ENTRY>
</ROW>
<ROW>
<ENTRY>NetBSD-current</ENTRY>
<ENTRY>NS32532</ENTRY>
<ENTRY>v6.4</ENTRY>
<ENTRY>1998-10-27</ENTRY>
<ENTRY>small problems in date/time math
(<ULink url="mailto:jonb@metronet.com">Jon Buller</ULink>)</ENTRY>
</ROW>
<ROW>
<ENTRY>NetBSD/sparc 1.3H</ENTRY>
<ENTRY>Sparc</ENTRY>
<ENTRY>v6.4</ENTRY>
<ENTRY>1998-10-27</ENTRY>
<ENTRY>(<ULink url="mailto:tih@hamartun.priv.no">Tom I Helbekkmo</ULink>)</ENTRY>
</ROW>
<ROW>
<ENTRY>NetBSD 1.3</ENTRY>
<ENTRY>VAX</ENTRY>
<ENTRY>v6.3</ENTRY>
<ENTRY>1998-03-01</ENTRY>
<ENTRY>(<ULink url="mailto:tih@hamartun.priv.no">Tom I Helbekkmo</ULink>)</ENTRY>
</ROW>
<ROW>
<ENTRY>SCO UnixWare 2.x</ENTRY>
<ENTRY>x86</ENTRY>
<ENTRY>v6.3</ENTRY>
<ENTRY>1998-03-01</ENTRY>
<ENTRY>aka UNIVEL
(<ULink url="mailto:Bill.Allie@mug.org">Billy G. Allie</ULink>)</ENTRY>
</ROW>
<ROW>
<ENTRY>SCO UnixWare 7</ENTRY>
<ENTRY>x86</ENTRY>
<ENTRY>v6.4</ENTRY>
<ENTRY>1998-10-04</ENTRY>
<ENTRY>(<ULink url="mailto:Bill.Allie@mug.org">Billy G. Allie</ULink>)</ENTRY>
</ROW>
<ROW>
<ENTRY>Solaris</ENTRY>
<ENTRY>x86</ENTRY>
<ENTRY>v6.4</ENTRY>
<ENTRY>1998-10-28</ENTRY>
<ENTRY>(<ULink url="mailto:scrappy@hub.org">Marc Fournier</ULink>)</ENTRY>
</ROW>
<ROW>
<ENTRY>Solaris 2.6-2.7</ENTRY>
<ENTRY>Sparc</ENTRY>
<ENTRY>v6.4</ENTRY>
<ENTRY>1998-10-28</ENTRY>
<ENTRY>(<ULink url="mailto:szybist@boxhill.com">Tom Szybist</ULink>,
<ULink url="mailto:ridderbusch.pad@sni.de">Frank Ridderbusch</ULink>)</ENTRY>
</ROW>
<ROW>
<ENTRY>SunOS 4.1.4</ENTRY>
<ENTRY>Sparc</ENTRY>
<ENTRY>v6.3</ENTRY>
<ENTRY>1998-03-01</ENTRY>
<ENTRY>Patches submitted
(<ULink url="mailto:t-ishii@sra.co.jp">Tatsuo Ishii</ULink>)</ENTRY>
</ROW>
<ROW>
<ENTRY>SVR4</ENTRY>
<ENTRY>MIPS</ENTRY>
<ENTRY>v6.4</ENTRY>
<ENTRY>1998-10-28</ENTRY>
<ENTRY>No 64-bit int compiler support
(<ULink url="mailto:ridderbusch.pad@sni.de">Frank Ridderbusch</ULink>)</ENTRY>
</ROW>
<ROW>
<ENTRY>Windows</ENTRY>
<ENTRY>x86</ENTRY>
<ENTRY>v6.4</ENTRY>
<ENTRY>1999-01-06</ENTRY>
<ENTRY>Client-side libraries or ODBC/JDBC. No server yet.
(<ulink url="mha@sollentuna.net">Magnus Hagander</ulink></ENTRY>
</ROW>
<ROW>
<ENTRY>Windows NT</ENTRY>
<ENTRY>x86</ENTRY>
<ENTRY>v6.4</ENTRY>
<ENTRY>1998-10-08</ENTRY>
<ENTRY>Working with the Cygwin library.
(<ulink url="mailto:Dan.Horak@email.cz">Horak Daniel</ulink>) </ENTRY>
</ROW>
</TBODY>
</TGROUP>
</TABLE>
</para>
<ulink url="mailto:t-ishii@sra.co.jp">Tatsuo Ishii</ulink>)</entry>
</row>
<row>
<entry>NetBSD-current</entry>
<entry>NS32532</entry>
<entry>v6.4</entry>
<entry>1998-10-27</entry>
<entry>small problems in date/time math
(<ulink url="mailto:jonb@metronet.com">Jon Buller</ulink>)</entry>
</row>
<row>
<entry>NetBSD/sparc 1.3H</entry>
<entry>Sparc</entry>
<entry>v6.4</entry>
<entry>1998-10-27</entry>
<entry>(<ulink url="mailto:tih@hamartun.priv.no">Tom I Helbekkmo</ulink>)</entry>
</row>
<row>
<entry>NetBSD 1.3</entry>
<entry>VAX</entry>
<entry>v6.3</entry>
<entry>1998-03-01</entry>
<entry>(<ulink url="mailto:tih@hamartun.priv.no">Tom I Helbekkmo</ulink>)</entry>
</row>
<row>
<entry>SCO OpenServer 5</entry>
<entry>x86</entry>
<entry>v6.5</entry>
<entry>1999-05-25</entry>
<entry>(<ulink url="mailto:andrew@compclass.com">Andrew Merrill</ulink>)</entry>
</row>
<row>
<entry>SCO UnixWare 7</entry>
<entry>x86</entry>
<entry>v6.5</entry>
<entry>1999-05-25</entry>
<entry>(<ulink url="mailto:andrew@compclass.com">Andrew Merrill</ulink>)</entry>
</row>
<row>
<entry>Solaris</entry>
<entry>x86</entry>
<entry>v6.4</entry>
<entry>1998-10-28</entry>
<entry>(<ulink url="mailto:scrappy@hub.org">Marc Fournier</ulink>)</entry>
</row>
<row>
<entry>Solaris 2.6-2.7</entry>
<entry>Sparc</entry>
<entry>v6.4</entry>
<entry>1998-10-28</entry>
<entry>(<ulink url="mailto:szybist@boxhill.com">Tom Szybist</ulink>,
<ulink url="mailto:ridderbusch.pad@sni.de">Frank Ridderbusch</ulink>)</entry>
</row>
<row>
<entry>SunOS 4.1.4</entry>
<entry>Sparc</entry>
<entry>v6.3</entry>
<entry>1998-03-01</entry>
<entry>Patches submitted
(<ulink url="mailto:t-ishii@sra.co.jp">Tatsuo Ishii</ulink>)</entry>
</row>
<row>
<entry>SVR4</entry>
<entry>MIPS</entry>
<entry>v6.4</entry>
<entry>1998-10-28</entry>
<entry>No 64-bit int compiler support
(<ulink url="mailto:ridderbusch.pad@sni.de">Frank Ridderbusch</ulink>)</entry>
</row>
<row>
<entry>Windows</entry>
<entry>x86</entry>
<entry>v6.4</entry>
<entry>1999-01-06</entry>
<entry>Client-side libraries or ODBC/JDBC. No server yet.
(<ulink url="mha@sollentuna.net">Magnus Hagander</ulink></entry>
</row>
<row>
<entry>Windows NT</entry>
<entry>x86</entry>
<entry>v6.4</entry>
<entry>1998-10-08</entry>
<entry>Working with the Cygwin library.
(<ulink url="mailto:Dan.Horak@email.cz">Horak Daniel</ulink>) </entry>
</row>
</tbody>
</tgroup>
</table>
</para>
<para>
Platforms listed for v6.3.x should also work with v6.4, but we did not receive
confirmation of such at the time this list was compiled.
</para>
<note>
<para>
For <productname>Windows NT</productname>,
the server-side port of <productname>Postgres</productname> has recently been
accomplished. The Cygnus library is required to compile it.
</para>
</note>
</sect1>
<para>
Platforms listed for v6.3.x and v6.4.x should also work with v6.5,
but we did not receive explicit confirmation of such at the time this
list was compiled.
</para>
<note>
<para>
For <productname>Windows NT</productname>,
the server-side port of <productname>Postgres</productname> has recently been
accomplished. The Cygnus library is required to compile it.
</para>
</note>
</sect1>
<Sect1>
<Title>Unsupported Platforms</Title>
<sect1>
<title>Unsupported Platforms</title>
<Para>
There are a few platforms which have been attempted and which have been
reported to not work with the standard distribution.
Others listed here do not provide sufficient library support for an attempt.
<para>
There are a few platforms which have been attempted and which have been
reported to not work with the standard distribution.
Others listed here do not provide sufficient library support for an attempt.
<TABLE TOCENTRY="1">
<TITLE>Possibly Incompatible Platforms</TITLE>
<TITLEABBREV>Incompatibles</TITLEABBREV>
<TGROUP COLS="4">
<THEAD>
<ROW>
<ENTRY><Acronym>OS</Acronym></ENTRY>
<ENTRY>Processor</ENTRY>
<ENTRY>Version</ENTRY>
<ENTRY>Reported</ENTRY>
<ENTRY>Remarks</ENTRY>
</ROW>
</THEAD>
<TBODY>
<ROW>
<ENTRY>MacOS</ENTRY>
<ENTRY>all</ENTRY>
<ENTRY>v6.3</ENTRY>
<ENTRY>1998-03-01</ENTRY>
<ENTRY>Not library compatible; use ODBC/JDBC</ENTRY>
</ROW>
<ROW>
<ENTRY>NetBSD</ENTRY>
<ENTRY>arm32</ENTRY>
<ENTRY>v6.3</ENTRY>
<ENTRY>1998-03-01</ENTRY>
<ENTRY>Not yet working (<ULink url="mailto:dmill@globalnet.co.uk">Dave Millen</ULink>)</ENTRY>
</ROW>
<ROW>
<ENTRY>NextStep</ENTRY>
<ENTRY>x86</ENTRY>
<ENTRY>v6.x</ENTRY>
<ENTRY>1998-03-01</ENTRY>
<ENTRY>Client-only support; v1.0.9 worked with patches (<ULink url="mailto:dave@turbocat.de">David Wetzel</ULink>)</ENTRY>
</ROW>
<ROW>
<ENTRY>SVR4 4.4</ENTRY>
<ENTRY>m88k</ENTRY>
<ENTRY>v6.2.1</ENTRY>
<ENTRY>1998-03-01</ENTRY>
<ENTRY>Confirmed with patching; v6.4.x will need TAS spinlock code
(<ULink url="mailto:dlw@seavme.xroads.com">Doug Winterburn</ULink>)</ENTRY>
</ROW>
<ROW>
<ENTRY>Ultrix</ENTRY>
<ENTRY>MIPS,VAX?</ENTRY>
<ENTRY>v6.x</ENTRY>
<ENTRY>1998-03-01</ENTRY>
<ENTRY>No recent reports; obsolete?</ENTRY>
</ROW>
</TBODY>
</TGROUP>
</TABLE>
</para>
<table tocentry="1">
<title>Possibly Incompatible Platforms</title>
<titleabbrev>Incompatibles</titleabbrev>
<tgroup cols="4">
<thead>
<row>
<entry><acronym>OS</acronym></entry>
<entry>Processor</entry>
<entry>Version</entry>
<entry>Reported</entry>
<entry>Remarks</entry>
</row>
</thead>
<tbody>
<row>
<entry>MacOS</entry>
<entry>all</entry>
<entry>v6.3</entry>
<entry>1998-03-01</entry>
<entry>Not library compatible; use ODBC/JDBC</entry>
</row>
<row>
<entry>NextStep</entry>
<entry>x86</entry>
<entry>v6.x</entry>
<entry>1998-03-01</entry>
<entry>Client-only support; v1.0.9 worked with patches (<ulink
url="mailto:dave@turbocat.de">David Wetzel</ulink>)</entry>
</row>
<row>
<entry>SVR4 4.4</entry>
<entry>m88k</entry>
<entry>v6.2.1</entry>
<entry>1998-03-01</entry>
<entry>Confirmed with patching; v6.4.x will need TAS spinlock code
(<ulink url="mailto:dlw@seavme.xroads.com">Doug Winterburn</ulink>)</entry>
</row>
<row>
<entry>Ultrix</entry>
<entry>MIPS,VAX?</entry>
<entry>v6.x</entry>
<entry>1998-03-01</entry>
<entry>No recent reports; obsolete?</entry>
</row>
</tbody>
</tgroup>
</table>
</para>
</Sect1>
</sect1>
</Chapter>
</chapter>
<!-- Keep this comment at the end of the file
Local variables:

50
doc/src/sgml/postgres.sgml
View File

@ -1,11 +1,18 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/postgres.sgml,v 1.23 1999/05/22 02:27:24 thomas Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/postgres.sgml,v 1.24 1999/05/26 17:30:29 thomas Exp $
Postgres integrated documentation.
Other subset docs should be copied and shrunk from here.
thomas 1998-02-23
$Log: postgres.sgml,v $
Revision 1.24 1999/05/26 17:30:29 thomas
Add chapters on CVS access, MVCC, SQL theory to the docs.
Add an appendix with more details on date/time attributes and handling.
Update most references to Postgres version numbers to 6.5,
*except* for the porting list which will require a report
from a successful installation to be updated.
Revision 1.23 1999/05/22 02:27:24 thomas
Finish initial markup of cvs.sgml, and include it in the programmer's guide
and the integrated doc. Clean up other markup.
@ -100,6 +107,7 @@ Move SQL reference pages up into the User's Guide.
<!entity inherit SYSTEM "inherit.sgml">
<!entity keys SYSTEM "keys.sgml">
<!entity manage SYSTEM "manage.sgml">
<!entity mvcc SYSTEM "mvcc.sgml">
<!entity oper SYSTEM "oper.sgml">
<!entity pgaccess SYSTEM "pgaccess.sgml">
<!entity psql SYSTEM "psql.sgml">
@ -125,6 +133,7 @@ Move SQL reference pages up into the User's Guide.
<!entity release SYSTEM "release.sgml">
<!entity security SYSTEM "security.sgml">
<!entity start-ag SYSTEM "start-ag.sgml">
<!entity trouble SYSTEM "trouble.sgml">
<!-- programmer's guide -->
<!entity intro-pg SYSTEM "intro-pg.sgml">
@ -156,6 +165,7 @@ Move SQL reference pages up into the User's Guide.
<!entity bki SYSTEM "bki.sgml">
<!entity compiler SYSTEM "compiler.sgml">
<!entity contacts SYSTEM "contacts.sgml">
<!entity cvs SYSTEM "cvs.sgml">
<!entity docguide SYSTEM "docguide.sgml">
<!entity geqo SYSTEM "geqo.sgml">
<!entity options SYSTEM "pg_options.sgml">
@ -193,12 +203,12 @@ Move SQL reference pages up into the User's Guide.
<AuthorInitials>TGL</AuthorInitials>
-->
<Date>(last updated 1998-05-19)</Date>
<Date>(last updated 1999-06-01)</Date>
</BookBiblio>
<LegalNotice>
<Para>
<ProductName>PostgreSQL</ProductName> is copyright (C) 1998
<ProductName>PostgreSQL</ProductName> is &copy; 1998-9
by the Postgres Global Development Group.
</Para>
</LegalNotice>
@ -255,19 +265,20 @@ Your name here...
</Para>
</PartIntro>
&sql;
&syntax;
&datatype;
&oper;
&func;
&typeconv;
&keys;
&array;
&inherit;
&environ;
&manage;
&storage;
&commands;
&sql;
&syntax;
&datatype;
&oper;
&func;
&typeconv;
&keys;
&array;
&inherit;
&mvcc;
&environ;
&manage;
&storage;
&commands;
</Part>
<part Id="part-admin">
@ -285,6 +296,7 @@ Your name here...
&runtime;
&security;
&start-ag;
&trouble;
&recovery;
&regress;
&release;
@ -356,8 +368,10 @@ Your name here...
Additional related information.
</Para>
</PartIntro>
&datetime;
&docguide;
&datetime;
&cvs;
&docguide;
<!--
&contacts;
-->

13
doc/src/sgml/programmer.sgml
View File

@ -1,10 +1,17 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/programmer.sgml,v 1.15 1999/05/22 02:27:24 thomas Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/programmer.sgml,v 1.16 1999/05/26 17:30:30 thomas Exp $
Postgres Programmer's Guide.
- thomas 1998-10-27
$Log: programmer.sgml,v $
Revision 1.16 1999/05/26 17:30:30 thomas
Add chapters on CVS access, MVCC, SQL theory to the docs.
Add an appendix with more details on date/time attributes and handling.
Update most references to Postgres version numbers to 6.5,
*except* for the porting list which will require a report
from a successful installation to be updated.
Revision 1.15 1999/05/22 02:27:24 thomas
Finish initial markup of cvs.sgml, and include it in the programmer's guide
and the integrated doc. Clean up other markup.
@ -136,12 +143,12 @@ Bigger updates to the installation instructions (install and config).
<AuthorInitials>TGL</AuthorInitials>
-->
<Date>(last updated 1999-05-19)</Date>
<Date>(last updated 1999-06-01)</Date>
</BookBiblio>
<LegalNotice>
<Para>
<ProductName>PostgreSQL</ProductName> is copyright (&copy;) 1998-9
<ProductName>PostgreSQL</ProductName> is &copy; 1998-9
by the Postgres Global Development Group.
</Para>
</LegalNotice>

15
doc/src/sgml/reference.sgml
View File

@ -1,10 +1,17 @@
<!-- reference.sgml
$Header: /cvsroot/pgsql/doc/src/sgml/reference.sgml,v 1.5 1998/10/31 09:36:37 thomas Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/reference.sgml,v 1.6 1999/05/26 17:30:30 thomas Exp $
Postgres User's Reference documentation.
- thomas 1998-08-31
$Log: reference.sgml,v $
Revision 1.6 1999/05/26 17:30:30 thomas
Add chapters on CVS access, MVCC, SQL theory to the docs.
Add an appendix with more details on date/time attributes and handling.
Update most references to Postgres version numbers to 6.5,
*except* for the porting list which will require a report
from a successful installation to be updated.
Revision 1.5 1998/10/31 09:36:37 thomas
Cleanup for v6.4 release.
Make new file current.sgml to hold release info for the current release.
@ -32,7 +39,7 @@ Bigger updates to the installation instructions (install and config).
<Title>PostgreSQL Reference Manual</Title>
<BookInfo>
<ReleaseInfo>Covering v6.4 for general release</ReleaseInfo>
<ReleaseInfo>Covering v6.5 for general release</ReleaseInfo>
<BookBiblio>
<AuthorGroup>
<Author>
@ -69,12 +76,12 @@ Bigger updates to the installation instructions (install and config).
</AuthorGroup>
-->
<Date>(last updated 1998-08-31)</Date>
<Date>(last updated 1999-06-01)</Date>
</BookBiblio>
<LegalNotice>
<Para>
<ProductName>PostgreSQL</ProductName> is copyright (C) 1998
<ProductName>PostgreSQL</ProductName> is &copy; 1998-9
by the Postgres Global Development Group.
</Para>
</LegalNotice>

162
doc/src/sgml/sql.sgml
View File

@ -88,9 +88,9 @@
language. That means it is
based on the <firstterm>relational data model</firstterm>
first published by E.F. Codd in
1970. We will give a formal description of the relational model in
section <xref linkend="formal-notion" endterm="formal-notion">
<!--{\it Formal Notion of the Relational Data Model}-->
1970. We will give a formal description of the relational model
later (in
<xref linkend="formal-notion" endterm="formal-notion">)
but first we want to have a look at it from a more intuitive
point of view.
</para>
@ -101,7 +101,7 @@
A table consists of rows and columns where each row represents a
record and each column represents an attribute of the records
contained in the table.
Figure <xref linkend="supplier-fig" endterm="supplier-fig">
<xref linkend="supplier-fig" endterm="supplier-fig">
shows an example of a database consisting of three tables:
<itemizedlist>
@ -127,6 +127,7 @@
</para>
</listitem>
</itemizedlist>
<example>
<title id="supplier-fig">The Suppliers and Parts Database</title>
<programlisting>
@ -162,7 +163,7 @@
</sect1>
<sect1>
<title id="formal-notion">Formal Notion of the Relational Data Model</title>
<title id="formal-notion">Relational Data Model Formalities</title>
<para>
The mathematical concept underlying the relational model is the
@ -288,7 +289,7 @@ attributes are taken from. We often write a relation scheme as
<parameter>D<subscript>i</subscript></parameter>,
for each attribute
<parameter>A<subscript>i</subscript></parameter>,
1 &lt;&equals; <literal>i</literal> &lt;&equals; <literal>k</literal>,
1 &lt;= <literal>i</literal> &lt;= <literal>k</literal>,
where the values of the attributes are taken from. We often write
a relation scheme as
<literal>R(<parameter>A<subscript>1</subscript></parameter>,
@ -325,11 +326,11 @@ attributes are taken from. We often write a relation scheme as
integers. We define this by assigning a data type to each
attribute. The type of <classname>SNAME</classname> will be
<type>VARCHAR(20)</type> (this is the <acronym>SQL</acronym> type
for character strings of length &lt;&equals; 20),
for character strings of length &lt;= 20),
the type of <classname>SNO</classname> will be
<type>INTEGER</type>. With the assignment of a data type we also have selected
a domain for an attribute. The domain of <classname>SNAME</classname> is the set of all
character strings of length &lt;&equals; 20,
character strings of length &lt;= 20,
the domain of <classname>SNO</classname> is the set of
all integer numbers.
</para>
@ -337,11 +338,10 @@ attributes are taken from. We often write a relation scheme as
</sect1>
<sect1>
<title id="operations">Operations in the Relational Data
Model</title>
<title id="operations">Operations in the Relational Data Model</title>
<para>
In <xref linkend="formal-notion" endterm="formal-notion">
In the previous section (<xref linkend="formal-notion" endterm="formal-notion">)
we defined the mathematical notion of
the relational model. Now we know how the data can be stored using a
relational data model but we do not know what to do with all these
@ -483,8 +483,8 @@ attributes are taken from. We often write a relation scheme as
projecting out the duplicate column.
</para>
<example id="join-example">
<title>An Inner Join</title>
<example>
<title id="join-example">An Inner Join</title>
<para>
Let's have a look at the tables that are produced by evaluating the steps
@ -600,36 +600,41 @@ t<subscript>r</subscript>(A,B)=t&and;t<subscript>r</subscript>(C,D)=t<subscript>
<para>
For a more detailed description and definition of the relational
algebra refer to <citetitle>ullman</citetitle> or
<citetitle>date86</citetitle>.
algebra refer to [<xref linkend="ULL88" endterm="ULL88">] or
[<xref linkend="DATE94" endterm="DATE94">].
</para>
<para id="suppl-rel-alg">
Recall that we formulated all those relational operators to be able to
retrieve data from the database. Let's return to our example of
section <xref linkend="operations" endterm="operations">
where someone wanted to know the names of all
suppliers that sell the part <literal>Screw</literal>.
This question can be answered
using relational algebra by the following operation:
<example>
<title id="suppl-rel-alg">A Query Using Relational Algebra</title>
<para>
Recall that we formulated all those relational operators to be able to
retrieve data from the database. Let's return to our example from
the previous
section (<xref linkend="operations" endterm="operations">)
where someone wanted to know the names of all
suppliers that sell the part <literal>Screw</literal>.
This question can be answered
using relational algebra by the following operation:
&pi;<subscript>SUPPLIER.SNAME</subscript>(&sigma;<subscript>PART.PNAME='Screw'</subscript>(SUPPLIER &prod; SELLS &prod; PART))
<programlisting>
&pi;<subscript>SUPPLIER.SNAME</subscript>(&sigma;<subscript>PART.PNAME='Screw'</subscript>(SUPPLIER &prod; SELLS &prod; PART))
</programlisting>
</para>
</para>
<para>
We call such an operation a query. If we evaluate the above query
against the our example tables
(<xref linkend="supplier-fig" endterm="supplier-fig">)
we will obtain the following result:
<para>
We call such an operation a query. If we evaluate the above query
against the tables from figure
<xref linkend="supplier-fig" endterm="supplier-fig"> (The suppliers and
parts database) we will obtain the following result:
<programlisting>
<programlisting>
SNAME
-------
Smith
Adams
</programlisting>
</para>
</programlisting>
</para>
</example>
</sect2>
<sect2 id="rel-calc">
@ -662,8 +667,10 @@ t<subscript>r</subscript>(A,B)=t&and;t<subscript>r</subscript>(C,D)=t<subscript>
We want to discuss the tuple relational calculus only because it is
the one underlying the most relational languages. For a detailed
discussion on <acronym>DRC</acronym> (and also
<acronym>TRC</acronym>) see <citetitle>date86</citetitle> or
<citetitle>ullman</citetitle>.
<acronym>TRC</acronym>) see
[<xref linkend="DATE94" endterm="DATE94">]
or
[<xref linkend="ULL88" endterm="ULL88">].
</para>
</sect2>
@ -686,18 +693,19 @@ t<subscript>r</subscript>(A,B)=t&and;t<subscript>r</subscript>(C,D)=t<subscript>
<xref linkend="suppl-rel-alg" endterm="suppl-rel-alg">
using <acronym>TRC</acronym> we formulate the following query:
<programlisting>
{x(SNAME) &mid; x &isin; SUPPLIER &and; \nonumber
&exist; y &isin; SELLS &exist; z &isin; PART (y(SNO)=x(SNO) &and; \nonumber
z(PNO)=y(PNO) &and; \nonumber
z(PNAME)='Screw')} \nonumber
</programlisting>
</para>
<para>
Evaluating the query against the tables from figure
Evaluating the query against the tables from
<xref linkend="supplier-fig" endterm="supplier-fig">
(The suppliers and parts database)
again leads to the same result
as in example
as in
<xref linkend="suppl-rel-alg" endterm="suppl-rel-alg">.
</para>
</sect2>
@ -715,8 +723,9 @@ t<subscript>r</subscript>(A,B)=t&and;t<subscript>r</subscript>(C,D)=t<subscript>
algorithm</quote>) by which an arbitrary expression of the relational
calculus can be reduced to a semantically equivalent expression of
relational algebra. For a more detailed discussion on that refer to
<citetitle>date86</citetitle> and
<citetitle>ullman</citetitle>.
[<xref linkend="DATE94" endterm="DATE94">]
and
[<xref linkend="ULL88" endterm="ULL88">].
</para>
<para>
@ -733,7 +742,8 @@ t<subscript>r</subscript>(A,B)=t&and;t<subscript>r</subscript>(C,D)=t<subscript>
<title>The <acronym>SQL</acronym> Language</title>
<para>
As most modern relational languages <acronym>SQL</acronym> is based on the tuple
As is the case with most modern relational languages,
<acronym>SQL</acronym> is based on the tuple
relational calculus. As a result every query that can be formulated
using the tuple relational calculus (or equivalently, relational
algebra) can also be formulated using <acronym>SQL</acronym>. There are, however,
@ -781,7 +791,7 @@ t<subscript>r</subscript>(A,B)=t&and;t<subscript>r</subscript>(C,D)=t<subscript>
</para>
<sect2 id="select">
<title>Select</title>
<title id="select-title">Select</title>
<para>
The most often used command in <acronym>SQL</acronym> is the
@ -806,7 +816,7 @@ t<subscript>r</subscript>(A,B)=t&and;t<subscript>r</subscript>(C,D)=t<subscript>
<para>
Now we will illustrate the complex syntax of the SELECT statement
with various examples. The tables used for the examples are defined in
figure <xref linkend="supplier-fig" endterm="supplier-fig"> (The suppliers and parts database).
<xref linkend="supplier-fig" endterm="supplier-fig">.
</para>
<sect3>
@ -816,7 +826,7 @@ t<subscript>r</subscript>(A,B)=t&and;t<subscript>r</subscript>(C,D)=t<subscript>
Here are some simple examples using a SELECT statement:
<example>
<title>Simple Query with Qualification</title>
<title id="simple-query">Simple Query with Qualification</title>
<para>
To retrieve all tuples from table PART where the attribute PRICE is
greater than 10 we formulate the following query:
@ -858,8 +868,7 @@ t<subscript>r</subscript>(A,B)=t&and;t<subscript>r</subscript>(C,D)=t<subscript>
Note that the <acronym>SQL</acronym> SELECT corresponds to the
"projection" in relational algebra not to the "selection"
(see section <xref linkend="rel-alg" endterm="rel-alg">
(Relational Algebra).
(see <xref linkend="rel-alg" endterm="rel-alg"> for more details).
</para>
<para>
@ -953,7 +962,7 @@ t<subscript>r</subscript>(A,B)=t&and;t<subscript>r</subscript>(C,D)=t<subscript>
because there are common named attributes (SNO and PNO) among the
relations. Now we can distinguish between the common named attributes
by simply prefixing the attribute name with the alias name followed by
a dot. The join is calculated in the same way as shown in example
a dot. The join is calculated in the same way as shown in
<xref linkend="join-example" endterm="join-example">.
First the Cartesian product
@ -979,7 +988,7 @@ t<subscript>r</subscript>(A,B)=t&and;t<subscript>r</subscript>(C,D)=t<subscript>
section).
<example>
<title>Aggregates</title>
<title id="aggregates-example">Aggregates</title>
<para>
If we want to know the average cost of all parts in table PART we use
@ -1048,7 +1057,7 @@ t<subscript>r</subscript>(A,B)=t&and;t<subscript>r</subscript>(C,D)=t<subscript>
A<subscript>1</subscript>, &tdot;, A<subscript>k</subscript>.
<example>
<title>Aggregates</title>
<title id="aggregates-groupby">Aggregates</title>
<para>
If we want to know how many parts are sold by every supplier we
formulate the query:
@ -1143,7 +1152,7 @@ t<subscript>r</subscript>(A,B)=t&and;t<subscript>r</subscript>(C,D)=t<subscript>
clause.
<example>
<title>Having</title>
<title id="having-example">Having</title>
<para>
If we want only those suppliers selling more than one part we use the
@ -1182,7 +1191,7 @@ t<subscript>r</subscript>(A,B)=t&and;t<subscript>r</subscript>(C,D)=t<subscript>
<acronym>SQL</acronym>.
<example>
<title>Subselect</title>
<title id="subselect-example">Subselect</title>
<para>
If we want to know all parts having a greater price than the part
@ -1250,7 +1259,7 @@ t<subscript>r</subscript>(A,B)=t&and;t<subscript>r</subscript>(C,D)=t<subscript>
difference of the tuples derived by two subqueries.
<example>
<title>Union, Intersect, Except</title>
<title id="union-example">Union, Intersect, Except</title>
<para>
The following query is an example for UNION:
@ -1334,7 +1343,7 @@ The only tuple returned by both parts of the query is the one having $SNO=2$.
</para>
<sect3 id="create">
<title>Create Table</title>
<title id="create-title">Create Table</title>
<para>
The most fundamental command for data definition is the
@ -1349,10 +1358,10 @@ The only tuple returned by both parts of the query is the one having $SNO=2$.
</synopsis>
<example>
<title>Table Creation</title>
<title id="table-create">Table Creation</title>
<para>
To create the tables defined in figure
To create the tables defined in
<xref linkend="supplier-fig" endterm="supplier-fig"> the
following <acronym>SQL</acronym> statements are used:
@ -1467,7 +1476,7 @@ The only tuple returned by both parts of the query is the one having $SNO=2$.
<para>
<example>
<title>Create Index</title>
<title id="index-create">Create Index</title>
<para>
To create an index named I on attribute SNAME of relation SUPPLIER
@ -1506,7 +1515,8 @@ The only tuple returned by both parts of the query is the one having $SNO=2$.
stored data. Instead, the system stores the definition of the
view (i.e. the rules about how to access physically stored base
tables in order to materialize the view) somewhere in the system
catalogs (see section <xref linkend="catalogs" endterm="catalogs">). For a
catalogs (see
<xref linkend="catalogs-title" endterm="catalogs-title">). For a
discussion on different techniques to implement views refer to
<!--
section
@ -1527,7 +1537,7 @@ The only tuple returned by both parts of the query is the one having $SNO=2$.
where <replaceable class="parameter">select_stmt</replaceable>
is a valid select statement as defined
in section <xref linkend="select" endterm="select">.
in <xref linkend="select-title" endterm="select-title">.
Note that <replaceable class="parameter">select_stmt</replaceable> is
not executed when the view is created. It is just stored in the
<firstterm>system catalogs</firstterm>
@ -1536,7 +1546,7 @@ The only tuple returned by both parts of the query is the one having $SNO=2$.
<para>
Let the following view definition be given (we use
the tables from figure <xref linkend="supplier-fig" endterm="supplier-fig"> again):
the tables from <xref linkend="supplier-fig" endterm="supplier-fig"> again):
<programlisting>
CREATE VIEW London_Suppliers
@ -1625,7 +1635,7 @@ The only tuple returned by both parts of the query is the one having $SNO=2$.
<para>
Once a table is created (see
<xref linkend="create" endterm="create">), it can be filled
<xref linkend="create-title" endterm="create-title">), it can be filled
with tuples using the command <command>INSERT INTO</command>.
The syntax is:
@ -1638,8 +1648,8 @@ The only tuple returned by both parts of the query is the one having $SNO=2$.
</para>
<para>
To insert the first tuple into the relation SUPPLIER of figure
<xref linkend="supplier-fig" endterm="supplier-fig"> we use the
To insert the first tuple into the relation SUPPLIER (from
<xref linkend="supplier-fig" endterm="supplier-fig">) we use the
following statement:
<programlisting>
@ -1716,7 +1726,7 @@ The only tuple returned by both parts of the query is the one having $SNO=2$.
</sect2>
<sect2 id="catalogs">
<title>System Catalogs</title>
<title id="catalogs-title">System Catalogs</title>
<para>
In every <acronym>SQL</acronym> database system
@ -1772,18 +1782,23 @@ The only tuple returned by both parts of the query is the one having $SNO=2$.
</para>
<para>
A program using embedded <acronym>SQL</acronym> in a host language consists of statements
of the host language and of embedded <acronym>SQL</acronym> (ESQL) statements. Every ESQL
statement begins with the keywords EXEC SQL. The ESQL statements are
transformed to statements of the host language by a <firstterm>precompiler</firstterm>
A program using embedded <acronym>SQL</acronym>
in a host language consists of statements
of the host language and of
<firstterm>embedded <acronym>SQL</acronym></firstterm>
(<acronym>ESQL</acronym>) statements. Every <acronym>ESQL</acronym>
statement begins with the keywords <command>EXEC SQL</command>.
The <acronym>ESQL</acronym> statements are
transformed to statements of the host language
by a <firstterm>precompiler</firstterm>
(which usually inserts
calls to library routines that perform the various <acronym>SQL</acronym>
commands).
</para>
<para>
When we look at the examples throughout section
<xref linkend="select" endterm="select"> we
When we look at the examples throughout
<xref linkend="select-title" endterm="select-title"> we
realize that the result of the queries is very often a set of
tuples. Most host languages are not designed to operate on sets so we
need a mechanism to access every single tuple of the set of tuples
@ -1795,8 +1810,11 @@ The only tuple returned by both parts of the query is the one having $SNO=2$.
<para>
For a detailed discussion on embedded <acronym>SQL</acronym>
refer to <citetitle>date</citetitle>,
<citetitle>date86</citetitle> or <citetitle>ullman</citetitle>.
refer to
[<xref linkend="DATE97" endterm="DATE97">],
[<xref linkend="DATE94" endterm="DATE94">],
or
[<xref linkend="ULL88" endterm="ULL88">].
</para>
</sect2>
</sect1>

17
doc/src/sgml/user.sgml
View File

@ -1,11 +1,18 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/user.sgml,v 1.10 1999/05/22 02:27:25 thomas Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/user.sgml,v 1.11 1999/05/26 17:30:30 thomas Exp $
Postgres User's Manual.
Derived from postgres.sgml.
thomas 1998-02-24
$Log: user.sgml,v $
Revision 1.11 1999/05/26 17:30:30 thomas
Add chapters on CVS access, MVCC, SQL theory to the docs.
Add an appendix with more details on date/time attributes and handling.
Update most references to Postgres version numbers to 6.5,
*except* for the porting list which will require a report
from a successful installation to be updated.
Revision 1.10 1999/05/22 02:27:25 thomas
Finish initial markup of cvs.sgml, and include it in the programmer's guide
and the integrated doc. Clean up other markup.
@ -60,6 +67,7 @@ Move SQL reference pages up into the User's Guide.
<!entity intro SYSTEM "intro.sgml">
<!entity keys SYSTEM "keys.sgml">
<!entity manage SYSTEM "manage.sgml">
<!entity mvcc SYSTEM "mvcc.sgml">
<!entity oper SYSTEM "oper.sgml">
<!entity sql SYSTEM "sql.sgml">
<!entity storage SYSTEM "storage.sgml">
@ -100,12 +108,12 @@ Move SQL reference pages up into the User's Guide.
<AuthorInitials>TGL</AuthorInitials>
-->
<Date>(last updated 1999-05-19)</Date>
<Date>(last updated 1999-06-01)</Date>
</BookBiblio>
<LegalNotice>
<Para>
<ProductName>PostgreSQL</ProductName> is copyright (&copy;) 1998-9
<ProductName>PostgreSQL</ProductName> is &copy; 1998-9
by the Postgres Global Development Group.
</Para>
</LegalNotice>
@ -150,11 +158,14 @@ Your name here...
&keys;
&array;
&inherit;
&mvcc;
&environ;
&manage;
&storage;
&commands;
<!-- appendices -->
&datetime;
<!--
&contacts;

354
doc/src/sgml/xoper.sgml
View File

@ -91,7 +91,7 @@ SELECT (a + b) AS c FROM test_complex;
sure that they are right! Incorrect use of an optimization clause can
result in backend crashes, subtly wrong output, or other Bad Things.
You can always leave out an optimization clause if you are not sure
about it --- the only consequence is that queries might run slower than
about it; the only consequence is that queries might run slower than
they need to.
</para>
@ -101,75 +101,80 @@ SELECT (a + b) AS c FROM test_complex;
the ones that release 6.5 understands.
</para>
<sect2>
<title>COMMUTATOR</title>
<sect2>
<title>COMMUTATOR</title>
<para>
The COMMUTATOR clause, if provided, names an operator that is the
commutator of the operator being defined. We say that operator A is the
commutator of operator B if (x A y) equals (y B x) for all possible input
values x,y. Notice that B is also the commutator of A. For example,
operators '<' and '>' for a particular datatype are usually each others'
commutators, and operator '+' is usually commutative with itself.
But operator '-' is usually not commutative with anything.
</para>
<para>
The COMMUTATOR clause, if provided, names an operator that is the
commutator of the operator being defined. We say that operator A is the
commutator of operator B if (x A y) equals (y B x) for all possible input
values x,y. Notice that B is also the commutator of A. For example,
operators '<' and '>' for a particular datatype are usually each others'
commutators, and operator '+' is usually commutative with itself.
But operator '-' is usually not commutative with anything.
</para>
<para>
The left argument type of a commuted operator is the same as the
right argument type of its commutator, and vice versa. So the name of
the commutator operator is all that <ProductName>Postgres</ProductName>
needs to be given to look up the commutator, and that's all that need
be provided in the COMMUTATOR clause.
</para>
<para>
The left argument type of a commuted operator is the same as the
right argument type of its commutator, and vice versa. So the name of
the commutator operator is all that <ProductName>Postgres</ProductName>
needs to be given to look up the commutator, and that's all that need
be provided in the COMMUTATOR clause.
</para>
<para>
When you are defining a self-commutative operator, you just do it.
When you are defining a pair of commutative operators, things are
a little trickier: how can the first one to be defined refer to the
other one, which you haven't defined yet? There are two solutions
to this problem:
</para>
<para>
When you are defining a self-commutative operator, you just do it.
When you are defining a pair of commutative operators, things are
a little trickier: how can the first one to be defined refer to the
other one, which you haven't defined yet? There are two solutions
to this problem:
<para>
One way is to omit the COMMUTATOR clause in the first operator that
you define, and then provide one in the second operator's definition.
Since <ProductName>Postgres</ProductName> knows that commutative
operators come in pairs, when it sees the second definition it will
automatically go back and fill in the missing COMMUTATOR clause in
the first definition.
</para>
<itemizedlist>
<listitem>
<para>
One way is to omit the COMMUTATOR clause in the first operator that
you define, and then provide one in the second operator's definition.
Since <ProductName>Postgres</ProductName> knows that commutative
operators come in pairs, when it sees the second definition it will
automatically go back and fill in the missing COMMUTATOR clause in
the first definition.
</para>
</listitem>
<para>
The other, more straightforward way is just to include COMMUTATOR clauses
in both definitions. When <ProductName>Postgres</ProductName> processes
the first definition and realizes that COMMUTATOR refers to a non-existent
operator, the system will make a dummy entry for that operator in the
system's pg_operator table. This dummy entry will have valid data only
for the operator name, left and right argument types, and result type,
since that's all that <ProductName>Postgres</ProductName> can deduce
at this point. The first operator's catalog entry will link to this
dummy entry. Later, when you define the second operator, the system
updates the dummy entry with the additional information from the second
definition. If you try to use the dummy operator before it's been filled
in, you'll just get an error message. (Note: this procedure did not work
reliably in <ProductName>Postgres</ProductName> versions before 6.5,
but it is now the recommended way to do things.)
</para>
<listitem>
<para>
The other, more straightforward way is just to include COMMUTATOR clauses
in both definitions. When <ProductName>Postgres</ProductName> processes
the first definition and realizes that COMMUTATOR refers to a non-existent
operator, the system will make a dummy entry for that operator in the
system's pg_operator table. This dummy entry will have valid data only
for the operator name, left and right argument types, and result type,
since that's all that <ProductName>Postgres</ProductName> can deduce
at this point. The first operator's catalog entry will link to this
dummy entry. Later, when you define the second operator, the system
updates the dummy entry with the additional information from the second
definition. If you try to use the dummy operator before it's been filled
in, you'll just get an error message. (Note: this procedure did not work
reliably in <ProductName>Postgres</ProductName> versions before 6.5,
but it is now the recommended way to do things.)
</para>
</listitem>
</itemizedlist>
</para>
</sect2>
</sect2>
<sect2>
<title>NEGATOR</title>
<sect2>
<title>NEGATOR</title>
<para>
The NEGATOR clause, if provided, names an operator that is the
negator of the operator being defined. We say that operator A
is the negator of operator B if both return boolean results and
(x A y) equals NOT (x B y) for all possible inputs x,y.
Notice that B is also the negator of A.
For example, '<' and '>=' are a negator pair for most datatypes.
An operator can never be validly be its own negator.
</para>
<para>
The NEGATOR clause, if provided, names an operator that is the
negator of the operator being defined. We say that operator A
is the negator of operator B if both return boolean results and
(x A y) equals NOT (x B y) for all possible inputs x,y.
Notice that B is also the negator of A.
For example, '<' and '>=' are a negator pair for most datatypes.
An operator can never be validly be its own negator.
</para>
<para>
Unlike COMMUTATOR, a pair of unary operators could validly be marked
@ -288,129 +293,134 @@ SELECT (a + b) AS c FROM test_complex;
<para>
The HASHES clause, if present, tells the system that it is OK to
use the hash join method for a join based on this operator. HASHES
only makes sense for binary operators that return boolean --- and
in practice, the operator had better be equality for some data type.
only makes sense for binary operators that return boolean, and
in practice the operator had better be equality for some data type.
</para>
<para>
The assumption underlying hash join is that the join operator can
only return TRUE for pairs of left and right values that hash to the
same hash code. If two values get put in different hash buckets, the
join will never compare them at all, implicitly assuming that the
result of the join operator must be FALSE. So it never makes sense
to specify HASHES for operators that do not represent equality.
</para>
<para>
The assumption underlying hash join is that the join operator can
only return TRUE for pairs of left and right values that hash to the
same hash code. If two values get put in different hash buckets, the
join will never compare them at all, implicitly assuming that the
result of the join operator must be FALSE. So it never makes sense
to specify HASHES for operators that do not represent equality.
</para>
<para>
In fact, logical equality is not good enough either --- the operator
had better represent pure bitwise equality, because the hash function
will be computed on the memory representation of the values regardless
of what the bits mean. For example, equality of
time intervals is not bitwise equality; the interval equality operator
considers two time intervals equal if they have the same
duration, whether or not their endpoints are identical. What this means
is that a join using "=" between interval fields would yield different
results if implemented as a hash join than if implemented another way,
because a large fraction of the pairs that should match will hash to
different values and will never be compared by the hash join. But
if the optimizer chose to use a different kind of join, all the pairs
that the equality operator says are equal will be found.
We don't want that kind of inconsistency, so we don't mark interval
equality as hashable.
</para>
<para>
In fact, logical equality is not good enough either; the operator
had better represent pure bitwise equality, because the hash function
will be computed on the memory representation of the values regardless
of what the bits mean. For example, equality of
time intervals is not bitwise equality; the interval equality operator
considers two time intervals equal if they have the same
duration, whether or not their endpoints are identical. What this means
is that a join using "=" between interval fields would yield different
results if implemented as a hash join than if implemented another way,
because a large fraction of the pairs that should match will hash to
different values and will never be compared by the hash join. But
if the optimizer chose to use a different kind of join, all the pairs
that the equality operator says are equal will be found.
We don't want that kind of inconsistency, so we don't mark interval
equality as hashable.
</para>
<para>
There are also machine-dependent ways in which a hash join might fail
to do the right thing. For example, if your datatype
is a structure in which there may be uninteresting pad bits, it's unsafe
to mark the equality operator HASHES. (Unless, perhaps, you write
your other operators to ensure that the unused bits are always zero.)
Another example is that the FLOAT datatypes are unsafe for hash
joins. On machines that meet the IEEE floating point standard, minus
zero and plus zero are different values (different bit patterns) but
they are defined to compare equal. So, if float equality were marked
HASHES, a minus zero and a plus zero would probably not be matched up
by a hash join, but they would be matched up by any other join process.
</para>
<para>
There are also machine-dependent ways in which a hash join might fail
to do the right thing. For example, if your datatype
is a structure in which there may be uninteresting pad bits, it's unsafe
to mark the equality operator HASHES. (Unless, perhaps, you write
your other operators to ensure that the unused bits are always zero.)
Another example is that the FLOAT datatypes are unsafe for hash
joins. On machines that meet the IEEE floating point standard, minus
zero and plus zero are different values (different bit patterns) but
they are defined to compare equal. So, if float equality were marked
HASHES, a minus zero and a plus zero would probably not be matched up
by a hash join, but they would be matched up by any other join process.
</para>
<para>
The bottom line is that you should probably only use HASHES for
equality operators that are (or could be) implemented by memcmp().
</para>
<para>
The bottom line is that you should probably only use HASHES for
equality operators that are (or could be) implemented by memcmp().
</para>
</sect2>
</sect2>
<sect2>
<title>SORT1 and SORT2</title>
<sect2>
<title>SORT1 and SORT2</title>
<para>
The SORT clauses, if present, tell the system that it is OK to use
the merge join method for a join based on the current operator.
Both must be specified if either is. The current operator must be
equality for some pair of data types, and the SORT1 and SORT2 clauses
name the ordering operator ('<' operator) for the left and right-side
data types respectively.
</para>
<para>
The SORT clauses, if present, tell the system that it is permissible to use
the merge join method for a join based on the current operator.
Both must be specified if either is. The current operator must be
equality for some pair of data types, and the SORT1 and SORT2 clauses
name the ordering operator ('<' operator) for the left and right-side
data types respectively.
</para>
<para>
Merge join is based on the idea of sorting the left and righthand tables
into order and then scanning them in parallel. So, both data types must
be capable of being fully ordered, and the join operator must be one
that can only succeed for pairs of values that fall at the "same place"
in the sort order. In practice this means that the join operator must
behave like equality. But unlike hashjoin, where the left and right
data types had better be the same (or at least bitwise equivalent),
it is possible to mergejoin two
distinct data types so long as they are logically compatible. For
example, the int2-versus-int4 equality operator is mergejoinable.
We only need sorting operators that will bring both datatypes into a
logically compatible sequence.
</para>
<para>
Merge join is based on the idea of sorting the left and righthand tables
into order and then scanning them in parallel. So, both data types must
be capable of being fully ordered, and the join operator must be one
that can only succeed for pairs of values that fall at the "same place"
in the sort order. In practice this means that the join operator must
behave like equality. But unlike hashjoin, where the left and right
data types had better be the same (or at least bitwise equivalent),
it is possible to mergejoin two
distinct data types so long as they are logically compatible. For
example, the int2-versus-int4 equality operator is mergejoinable.
We only need sorting operators that will bring both datatypes into a
logically compatible sequence.
</para>
<para>
When specifying merge sort operators, the current operator and both
referenced operators must return boolean; the SORT1 operator must have
both input datatypes equal to the current operator's left argument type,
and the SORT2 operator must have
both input datatypes equal to the current operator's right argument type.
(As with COMMUTATOR and NEGATOR, this means that the operator name is
sufficient to specify the operator, and the system is able to make dummy
operator entries if you happen to define the equality operator before
the other ones.)
</para>
<para>
When specifying merge sort operators, the current operator and both
referenced operators must return boolean; the SORT1 operator must have
both input datatypes equal to the current operator's left argument type,
and the SORT2 operator must have
both input datatypes equal to the current operator's right argument type.
(As with COMMUTATOR and NEGATOR, this means that the operator name is
sufficient to specify the operator, and the system is able to make dummy
operator entries if you happen to define the equality operator before
the other ones.)
</para>
<para>
In practice you should only write SORT clauses for an '=' operator,
and the two referenced operators should always be named '<'. Trying
to use merge join with operators named anything else will result in
hopeless confusion, for reasons we'll see in a moment.
</para>
<para>
In practice you should only write SORT clauses for an '=' operator,
and the two referenced operators should always be named '<'. Trying
to use merge join with operators named anything else will result in
hopeless confusion, for reasons we'll see in a moment.
</para>
<para>
There are additional restrictions on operators that you mark
mergejoinable. These restrictions are not currently checked by
CREATE OPERATOR, but a merge join may fail at runtime if any are
not true:
</para>
<para>
There are additional restrictions on operators that you mark
mergejoinable. These restrictions are not currently checked by
CREATE OPERATOR, but a merge join may fail at runtime if any are
not true:
<para>
The mergejoinable equality operator must have a commutator
(itself if the two data types are the same, or a related equality operator
if they are different).
</para>
<itemizedlist>
<listitem>
<para>
The mergejoinable equality operator must have a commutator
(itself if the two data types are the same, or a related equality operator
if they are different).
</para>
</listitem>
<para>
There must be '<' and '>' ordering operators having the same left and
right input datatypes as the mergejoinable operator itself. These
operators <emphasis>must</emphasis> be named '<' and '>' --- you do
not have any choice in the matter, since there is no provision for
specifying them explicitly. Note that if the left and right data types
are different, neither of these operators is the same as either
SORT operator. But they had better order the data values compatibly
with the SORT operators, or mergejoin will fail to work.
</para>
</sect2>
<listitem>
<para>
There must be '<' and '>' ordering operators having the same left and
right input datatypes as the mergejoinable operator itself. These
operators <emphasis>must</emphasis> be named '<' and '>'; you do
not have any choice in the matter, since there is no provision for
specifying them explicitly. Note that if the left and right data types
are different, neither of these operators is the same as either
SORT operator. But they had better order the data values compatibly
with the SORT operators, or mergejoin will fail to work.
</para>
</listitem>
</itemizedlist>
</para>
</sect2>
</sect1>
</Chapter>