mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Finish initial markup of cvs.sgml, and include it in the programmer's guide

Browse Source 
and the integrated doc. Clean up other markup.
This commit is contained in:
Thomas G. Lockhart 1999-05-22 02:27:25 +00:00
parent 85170aa9b6
commit 654f8f0b51
9 changed files with 1323 additions and 1057 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

File diff suppressed because it is too large Load Diff

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

@ -1,155 +1,715 @@
From - Mon May 10 15:59:27 1999
Received: from localhost (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id PAA24871
for <lockhart@localhost>; Wed, 14 Apr 1999 15:45:24 GMT
Received: from apop-server.alumni.caltech.edu
by localhost with POP3 (fetchmail-4.7.9)
for lockhart@localhost (single-drop); Wed, 14 Apr 1999 15:45:26 +0000 (UTC)
Received: from bologna.nettuno.it (bologna.nettuno.it [193.43.2.1])
by alumnus.caltech.edu (8.9.1/8.9.1) with ESMTP id IAA18386
for <lockhart@alumni.caltech.edu>; Wed, 14 Apr 1999 08:41:45 -0700 (PDT)
Received: from proxy.sferacarta.com (mail@sfcabop1.nettuno.it [193.207.10.213])
by bologna.nettuno.it (8.8.6/8.8.6/NETTuno 3.1) with ESMTP id RAA15888;
Wed, 14 Apr 1999 17:41:33 +0200 (MDT)
Received: from rosso.sferacarta.com (sferacarta.com) [10.20.30.5]
by proxy.sferacarta.com with esmtp (Exim 2.05 #1 (Debian))
id 10XTfQ-00083Z-00; Wed, 14 Apr 1999 17:41:40 +0000
Message-ID: <3714B6B6.F745D41D@sferacarta.com>
Date: Wed, 14 Apr 1999 17:39:34 +0200
From: José Soares <jose@sferacarta.com>
X-Mailer: Mozilla 4.5 [it] (Win95; I)
X-Accept-Language: it
MIME-Version: 1.0
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
CC: hackers <pgsql-hackers@postgresql.org>,
general <pgsql-general@postgresql.org>
Subject: Re: [GENERAL] Re: [HACKERS] Gregorian Calendar
References: <3711B1E5.80213DF6@sferacarta.com> <37135951.88FDB948@alumni.caltech.edu>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=iso-8859-1
X-UIDL: 25f0580d2a532247ac6af3aee9737b7c
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/datetime.sgml,v 2.2 1999/05/22 02:27:23 thomas Exp $
Date/time details
Hi Thomas,
$Log: datetime.sgml,v $
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.
Thomas Lockhart ha scritto:
-->
> > I have a question about dates.
> > The Gregorian reform of calendar skiped 10 days on Oct, 1582.
> > This reform was accepted by Great Britain and Dominions (including
> > what is now the USA) only in 1752.
> > If I insert a date that doesn't exist PostgreSQL accepts it.
> > Should it be considered normal ?
>
> As Peter says, this is tricky.
>
> Date conventions before the 19th century make for interesting reading,
> but are not imho consistant enough to warrant coding into a date/time
> handler.
>
> As you probably have noticed, we use Julian date calculations for our
> date/time support.
<appendix label="UG1" id="datetime-append">
<title>Date/Time Support</title>
I suppose you refer to Julian Day invented by the French scholar
Joseph Justus Scaliger (1540-1609)
that probably takes its name from the Scaliger's father,
the Italian scholar Julius Caesar Scaliger (1484-1558).
Astronomers have used the Julian period to assign a unique number to
every day since 1 January 4713 BC. This is the so-called Julian Day
(JD). JD 0 designates the 24 hours from noon UTC on 1 January 4713 BC
to noon UTC on 2 January 4713 BC.
<sect1>
<title>Time Zones</title>
Julian Day is different from Julian Date
<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>
<note>
<para>
If the compiler option USE_AUSTRALIAN_RULES is set
then <literal>EST</literal> refers to Australia Eastern Std Time,
which has an offset of +10:00 hours from UTC.
</para>
</note>
</para>
The Julian calendar was introduced by Julius Caesar in 45 BC. It was
in common use until the 1582, when countries started changing to the
Gregorian calendar.
<para>
Australian time zones and their naming variants
account for fully one quarter of all time zones in the
<productname>Postgres</productname> time zone lookup table.
</para>
In the Julian calendar, the tropical year is approximated as 365 1/4
days = 365.25 days. This gives an error of 1 day in approximately 128
<procedure>
<title>Date/Time Input Interpretation</title>
and this is why pope Gregory XIII in accordance with instructions
from the Council of Trent reformed the calendar to correct this error.
<para>
The date/time types are all decoded using a common set of routines.
</para>
In the Gregorian calendar, the tropical year is approximated as
365 + 97 / 400 days = 365.2425 days. Thus it takes approximately 3300
years for the tropical year to shift one day with respect to the
Gregorian calendar.
<step>
<para>
Break the input string into tokens and categorize each token as
a string, time, time zone, or number.
</para>
The approximation 365+97/400 is achieved by having 97 leap years
every 400 years.
<substeps>
<step>
<para>
If the token contains a colon (":"), this is a time string.
</para>
</step>
The Gregorian calendar has 97 leap years every 400 years:
<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>
</sect1>
<sect1>
<title>History</title>
<note>
<para>
Contributed by
<ulink url="jose@sferacarta.com">José Soares</ulink>.
</para>
</note>
<para>
The Julian Day invented by the French scholar
Joseph Justus Scaliger (1540-1609)
and which probably takes its name from the Scaliger's father,
the Italian scholar Julius Caesar Scaliger (1484-1558).
Astronomers have used the Julian period to assign a unique number to
every day since 1 January 4713 BC. This is the so-called Julian Day
(JD). JD 0 designates the 24 hours from noon UTC on 1 January 4713 BC
to noon UTC on 2 January 4713 BC.
</para>
<para>
Julian Day is different from Julian Date.
The Julian calendar was introduced by Julius Caesar in 45 BC. It was
in common use until the 1582, when countries started changing to the
Gregorian calendar.
In the Julian calendar, the tropical year is approximated as 365 1/4
days = 365.25 days. This gives an error of 1 day in approximately
128 days.
The accumulating calendar error prompted pope Gregory XIII
to reform the calendar in accordance with instructions
from the Council of Trent.
</para>
<para>
In the Gregorian calendar, the tropical year is approximated as
365 + 97 / 400 days = 365.2425 days. Thus it takes approximately 3300
years for the tropical year to shift one day with respect to the
Gregorian calendar.
</para>
<para>
The approximation 365+97/400 is achieved by having 97 leap years
every 400 years, using the following rules:
<simplelist>
<member>
Every year divisible by 4 is a leap year.
</member>
<member>
However, every year divisible by 100 is not a leap year.
</member>
<member>
However, every year divisible by 400 is a leap year after all.
</member>
</simplelist>
So, 1700, 1800, 1900, 2100, and 2200 are not leap years. But 1600,
2000, and 2400 are leap years.
So, 1700, 1800, 1900, 2100, and 2200 are not leap years. But 1600,
2000, and 2400 are leap years.
instead in the Julian calendar only years divisible by 4 are leap years.
By contrast, in the older Julian calendar only years divisible by 4 are leap years.
</para>
The papal bull of February 1582 decreed that 10 days should be dropped
from October 1582 so that 15 October should follow immediately after
4 October.
This was observed in Italy, Poland, Portugal, and Spain. Other Catholic
countries followed shortly after, but Protestant countries were
reluctant to change, and the Greek orthodox countries didn't change
until the start of this century.
<para>
The papal bull of February 1582 decreed that 10 days should be dropped
from October 1582 so that 15 October should follow immediately after
4 October.
This was observed in Italy, Poland, Portugal, and Spain. Other Catholic
countries followed shortly after, but Protestant countries were
reluctant to change, and the Greek orthodox countries didn't change
until the start of this century.
The reform was observed by Great Britain and Dominions (including what is
now the USA)
in 1752.
The 2 Sep 1752 was followed by 14 Sep 1752.
The reform was observed by Great Britain and Dominions (including what is
now the USA) in 1752.
Thus 2 Sep 1752 was followed by 14 Sep 1752.
This is why unix has the cal 9 1752 like this:
This is why Unix systems have <application>cal</application>
produce the following:
<programlisting>
% cal 9 1752
September 1752
S M Tu W Th F S
1 2 14 15 16
1 2 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
</programlisting>
</para>
My question is:
^^^^^^^^^^^^
If SQL92 says:
(Second Informal Review Draft) ISO/IEC 9075:1992, Database
Language SQL- July 30, 1992
5.3 literals
22)Within the definition of a <datetime literal>, the <datetime
value>s are constrained by the natural rules for dates and
times
according to the Gregorian calendar.
^^^^^^^^^^^^^^^
Dates between 1752-09-03 and 1752-09-13.
Are they valid dates?
^^^^^^^^^^^^^^^^
> They have the nice property of correctly
> predicting/calculating any date more recent than something like 4013BC
> to far into the future, using the assumption that the length of the
> year is 365.25 days. This is a very recently adopted convention
> (sometime in the 1800s I had thought, but perhaps it was during the
> same "reform" in 1752).
>
> I've toyed with the idea of implementing a Chinese dynastic calendar,
> since it seems to be more predictable than historical European
> calendars.
People's Republic of China uses the Gregorian calendar
for civil purposes. Chinese calendar is used for determining
festivals.
The beginnings of the Chinese calendar can be traced back to the 14th
century BC. Legend has it that the Emperor Huangdi invented the
calendar in 2637 B
José
<note>
<para>
SQL92 states that
<quote>Within the definition of a <sgmltag>datetime literal</sgmltag>,
the <sgmltag>datetime value</sgmltag>s are constrained by the
natural rules for dates and times
according to the Gregorian calendar</quote>.
Dates between 1752-09-03 and 1752-09-13, although eliminated in
some countries by Papal fiat, conform to
<quote>natural rules</quote> and are hence valid dates.
</para>
</note>
<para>
Different calendars have been developed in various parts of the
world, many predating the Gregorian system.
For example,
the beginnings of the Chinese calendar can be traced back to the 14th
century BC. Legend has it that the Emperor Huangdi invented the
calendar in 2637 BC.
The People's Republic of China uses the Gregorian calendar
for civil purposes. Chinese calendar is used for determining
festivals.
</para>
</sect1>
</appendix>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-omittag:nil
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
sgml-parent-document:nil
sgml-default-dtd-file:"./reference.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:"/usr/lib/sgml/catalog"
sgml-local-ecat-files:nil
End:
-->

2
doc/src/sgml/pg_options.sgml
View File

@ -1,4 +1,4 @@
<Chapter Id="pg-options">
<Chapter Id="pg-options-dev">
<DocInfo>
<AuthorGroup>
<Author>

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

@ -1,11 +1,15 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/postgres.sgml,v 1.22 1999/05/20 05:39:27 thomas Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/postgres.sgml,v 1.23 1999/05/22 02:27:24 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.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.
Revision 1.22 1999/05/20 05:39:27 thomas
Rearrange and consolidate the Admin Guide.
Add reference pages for utilities and remove standalone chapters for same.
@ -90,6 +94,7 @@ Move SQL reference pages up into the User's Guide.
<!entity advanced SYSTEM "advanced.sgml">
<!entity array SYSTEM "array.sgml">
<!entity datatype SYSTEM "datatype.sgml">
<!entity datetime SYSTEM "datetime.sgml">
<!entity environ SYSTEM "environ.sgml">
<!entity func SYSTEM "func.sgml">
<!entity inherit SYSTEM "inherit.sgml">
@ -351,8 +356,11 @@ Your name here...
Additional related information.
</Para>
</PartIntro>
&docguide;
&datetime;
&docguide;
<!--
&contacts;
-->
&biblio;
</Part>

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

@ -1,10 +1,14 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/programmer.sgml,v 1.14 1999/05/20 05:39:27 thomas Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/programmer.sgml,v 1.15 1999/05/22 02:27:24 thomas Exp $
Postgres Programmer's Guide.
- thomas 1998-10-27
$Log: programmer.sgml,v $
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.
Revision 1.14 1999/05/20 05:39:27 thomas
Rearrange and consolidate the Admin Guide.
Add reference pages for utilities and remove standalone chapters for same.
@ -94,6 +98,7 @@ Bigger updates to the installation instructions (install and config).
<!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">
@ -216,6 +221,7 @@ Disable it until we put in some info.
<!-- appendices -->
&cvs;
&docguide;
<!--
&contacts;

3
doc/src/sgml/query.sgml
View File

@ -158,9 +158,6 @@ COPY INTO weather FROM '/home/user/weather.txt'
</para>
</sect1>
</Para>
</sect1>
<Sect1>
<Title>Querying a Class</Title>

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

@ -288,7 +288,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;&equal; <literal>i</literal> &lt;&equal; <literal>k</literal>,
1 &lt;&equals; <literal>i</literal> &lt;&equals; <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 +325,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;&equal; 20),
for character strings of length &lt;&equals; 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;&equal; 20,
character strings of length &lt;&equals; 20,
the domain of <classname>SNO</classname> is the set of
all integer numbers.
</para>

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

@ -1,11 +1,15 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/user.sgml,v 1.9 1999/05/20 05:39:29 thomas Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/user.sgml,v 1.10 1999/05/22 02:27:25 thomas Exp $
Postgres User's Manual.
Derived from postgres.sgml.
thomas 1998-02-24
$Log: user.sgml,v $
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.
Revision 1.9 1999/05/20 05:39:29 thomas
Rearrange and consolidate the Admin Guide.
Add reference pages for utilities and remove standalone chapters for same.
@ -49,6 +53,7 @@ Move SQL reference pages up into the User's Guide.
<!entity array SYSTEM "array.sgml">
<!entity biblio SYSTEM "biblio.sgml">
<!entity datatype SYSTEM "datatype.sgml">
<!entity datetime SYSTEM "datetime.sgml">
<!entity environ SYSTEM "environ.sgml">
<!entity func SYSTEM "func.sgml">
<!entity inherit SYSTEM "inherit.sgml">
@ -149,7 +154,8 @@ Your name here...
&manage;
&storage;
&commands;
&datetime;
<!--
&contacts;
-->

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

@ -186,7 +186,7 @@ SELECT (a + b) AS c FROM test_complex;
<para>
Providing NEGATOR is very helpful to the query optimizer since
it allows expressions like NOT (x = y) to be simplified into
x <> y. This comes up more often than you might think, because
x &lt;&gt; y. This comes up more often than you might think, because
NOTs can be inserted as a consequence of other rearrangements.
</para>
@ -225,21 +225,21 @@ SELECT (a + b) AS c FROM test_complex;
These are the standard restriction estimators:
<ProgramListing>
eqsel for =
neqsel for <>
intltsel for < or <=
intgtsel for > or >=
neqsel for &lt;&gt;
intltsel for &lt; or &lt;=
intgtsel for &gt; or &gt;=
</ProgramListing>
It might seem a little odd that these are the categories, but they
make sense if you think about it. '=' will typically accept only
a small fraction of the rows in a table; '<>' will typically reject
only a small fraction. '<' will accept a fraction that depends on
a small fraction of the rows in a table; '&lt;&gt;' will typically reject
only a small fraction. '&lt;' will accept a fraction that depends on
where the given constant falls in the range of values for that table
column (which, it just so happens, is information collected by
VACUUM ANALYZE and made available to the selectivity estimator).
'<=' will accept a slightly larger fraction than '<' for the same
'&lt;=' will accept a slightly larger fraction than '&lt;' for the same
comparison constant, but they're close enough to not be worth
distinguishing, especially since we're not likely to do better than a
rough guess anyhow. Similar remarks apply to '>' and '>='.
rough guess anyhow. Similar remarks apply to '&gt;' and '&gt;='.
</para>
<para>
@ -249,48 +249,48 @@ SELECT (a + b) AS c FROM test_complex;
matching operators (~, ~*, etc) use eqsel on the assumption that they'll
usually only match a small fraction of the entries in a table.
</para>
</sect2>
<sect2>
<title>JOIN</title>
<sect2>
<title>JOIN</title>
<para>
The JOIN clause, if provided, names a join selectivity
estimation function for the operator (note that this is a function
name, not an operator name). JOIN clauses only make sense for
binary operators that return boolean. The idea behind a join
selectivity estimator is to guess what fraction of the rows in a
pair of tables will satisfy a WHERE-clause condition of the form
<ProgramListing>
<para>
The JOIN clause, if provided, names a join selectivity
estimation function for the operator (note that this is a function
name, not an operator name). JOIN clauses only make sense for
binary operators that return boolean. The idea behind a join
selectivity estimator is to guess what fraction of the rows in a
pair of tables will satisfy a WHERE-clause condition of the form
<ProgramListing>
table1.field1 OP table2.field2
</ProgramListing>
for the current operator. As with the RESTRICT clause, this helps
the optimizer very substantially by letting it figure out which
of several possible join sequences is likely to take the least work.
</para>
</ProgramListing>
for the current operator. As with the RESTRICT clause, this helps
the optimizer very substantially by letting it figure out which
of several possible join sequences is likely to take the least work.
</para>
<para>
As before, this chapter will make no attempt to explain how to write
a join selectivity estimator function, but will just suggest that
you use one of the standard estimators if one is applicable:
<ProgramListing>
<para>
As before, this chapter will make no attempt to explain how to write
a join selectivity estimator function, but will just suggest that
you use one of the standard estimators if one is applicable:
<ProgramListing>
eqjoinsel for =
neqjoinsel for <>
intltjoinsel for < or <=
intgtjoinsel for > or >=
</ProgramListing>
</para>
neqjoinsel for &lt;&gt;
intltjoinsel for &lt; or &lt;=
intgtjoinsel for &gt; or &gt;=
</ProgramListing>
</para>
</sect2>
</sect2>
<sect2>
<title>HASHES</title>
<sect2>
<title>HASHES</title>
<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.
</para>
<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.
</para>
<para>
The assumption underlying hash join is that the join operator can