Skip to content

P
Postgres FD Implementation
Commit 654f8f0b authored by Thomas G. Lockhart's avatar Thomas G. Lockhart
Browse files
Options

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

 and the integrated doc. Clean up other markup.
parent 85170aa9
Hide whitespace changes
Inline Side-by-side
Showing with 1380 additions and 1114 deletions
doc/src/sgml/cvs.sgml
View file @ 654f8f0b
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/cvs.sgml,v 1.4 1999/04/06 15:38:10 thomas Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/cvs.sgml,v 1.5 1999/05/22 02:27:23 thomas Exp $
CVS code repository
Thomas Lockhart
$Log: cvs.sgml,v $
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.
Revision 1.4 1999/04/06 15:38:10 thomas
Start indenting markup. No text changes.
......@@ -21,29 +25,38 @@ Not yet included in a document (should go in the developer's doc?).
-->
<appendix label="A" id="cvs">
<docinfo>
<authorgroup>
<author>
<firstname>Marc</firstname>
<surname>Fournier</surname>
</author>
</authorgroup>
<date>1998-12-01</date>
</docinfo>
<title>The <productname>Postgres</productname> <productname>CVS</productname> Repository</title>
<appendix label="DG1" id="cvs">
<docinfo>
<authorgroup>
<author>
<firstname>Marc</firstname>
<surname>Fournier</surname>
</author>
<author>
<firstname>Tom</firstname>
<surname>Lane</surname>
</author>
<author>
<firstname>Thomas</firstname>
<surname>Lockhart</surname>
</author>
</authorgroup>
<date>1999-05-20</date>
</docinfo>
<title>The <productname>CVS</productname> Repository</title>
<para>
The <productname>Postgres</productname> source code is stored and managed using the
<productname>CVS</productname> code management system.
</para>
At least two options,
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.
</para>
<para>
At least two options,
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.
</para>
<sect1>
<title><productname>CVS</productname> Tree Organization</title>
......@@ -53,37 +66,39 @@ Not yet included in a document (should go in the developer's doc?).
<title>Author</title>
<para>
Written by <ulink url="mailto:scrappy@hub.org">Marc G. Fournier</ulink> on 1998-11-05.
</para>
</note>
</para>
<para>
<para>
The command <command>cvs checkout</command> has a flag, <option>-r</option>,
that lets you check out a
certain revision of a module. This flag makes it easy to, for example,
retrieve the
sources that make up release 1.0 of the module `tc' at any time in the
future:
that lets you check out a
certain revision of a module. This flag makes it easy to, for example,
retrieve the
sources that make up release 1.0 of the module `tc' at any time in the
future:
<programlisting>
<programlisting>
$ cvs checkout -r REL6_4 tc
</programlisting>
</programlisting>
This is useful, for instance, if someone claims that there is a bug in
that release, but you cannot find the bug in the current working copy.
This is useful, for instance, if someone claims that there is a bug in
that release, but you cannot find the bug in the current working copy.
<tip>
<para>
You can also check out a module as it was at any given date using the
<option>-D</option> option.
</tip>
</para>
<tip>
<para>
You can also check out a module as it was at any given date using the
<option>-D</option> option.
</para>
</tip>
</para>
<para>
<para>
When you tag more than one file with the same tag you can think
about the tag as "a curve drawn through a matrix of filename vs.
revision number". Say we have 5 files with the following revisions:
<programlisting>
about the tag as "a curve drawn through a matrix of filename vs.
revision number". Say we have 5 files with the following revisions:
<programlisting>
file1 file2 file3 file4 file5
1.1 1.1 1.1 1.1 /--1.1* <-*- TAG
......@@ -92,466 +107,598 @@ revision number". Say we have 5 files with the following revisions:
1.4 \ 1.4 / 1.4
\-1.5*- 1.5
1.6
</programlisting>
</programlisting>
then the tag <quote><literal>TAG</literal></quote> will reference
file1-1.2, file2-1.3, etc.
then the tag <quote><literal>TAG</literal></quote> will reference
file1-1.2, file2-1.3, etc.
<note>
<para>
For creating a release branch, other then a
-b option added to the command, it's the same thing.
</note>
</para>
<note>
<para>
For creating a release branch, other then a
-b option added to the command, it's the same thing.</para>
</note>
</para>
<para>
So, to create the v6.4 release
I will be doing the following:
<para>
So, to create the v6.4 release
I did the following:
<programlisting>
<programlisting>
$ cd pgsql
$ cvs tag -b REL6_4
</programlisting>
</programlisting>
which will create the tag and the branch for the RELEASE tree.
</para>
which will create the tag and the branch for the RELEASE tree.
</para>
<para>
Now, for those with <productname>CVS</productname> access, it's too simple.
First, create two subdirectories, RELEASE and CURRENT, so that you don't
mix up the two. Then do:
<para>
Now, for those with <productname>CVS</productname> access, it's too simple.
First, create two subdirectories, RELEASE and CURRENT, so that you don't
mix up the two. Then do:
<programlisting>
<programlisting>
cd RELEASE
cvs checkout -P -r REL6_4 pgsql
cd ../CURRENT
cvs checkout -P pgsql
</programlisting>
</programlisting>
which results in two directory trees, <filename>RELEASE/pgsql</filename> and
<filename>CURRENT/pgsql</filename>. From that point on, <productname>CVS</productname>
will keep track of which repository branch is in which directory tree, and will
allow independent updates of either tree.
</para>
which results in two directory trees, <filename>RELEASE/pgsql</filename> and
<filename>CURRENT/pgsql</filename>. From that point on,
<productname>CVS</productname>
will keep track of which repository branch is in which directory tree, and will
allow independent updates of either tree.
</para>
<para>
If you are <emphasis>only</emphasis> working on the <literal>CURRENT</literal>
source tree, you just do
everything as before we started tagging release branches.
</para>
<para>
If you are <emphasis>only</emphasis> working on the <literal>CURRENT</literal>
source tree, you just do
everything as before we started tagging release branches.
</para>
<para>
After you've done the initial checkout on a branch
<para>
After you've done the initial checkout on a branch
<programlisting>
<programlisting>
$ cvs checkout -r REL6_4
</programlisting>
</programlisting>
anything you do within that directory structure is restricted to that
branch. If you apply a patch to that directory structure and do a
anything you do within that directory structure is restricted to that
branch. If you apply a patch to that directory structure and do a
<programlisting>
<programlisting>
cvs commit
</programlisting>
while inside of it, the patch is applied to the branch and
<emphasis>only</emphasis> the branch.
</para>
</sect1>
<sect1>
<title>Getting The Source Via Anonymous <productname>CVS</productname></title>
<para>
If you would like to keep up with the current sources on a regular
basis, you can fetch them from our <productname>CVS</productname> server
and then use <productname>CVS</productname> to
retrieve updates from time to time.
</para>
<procedure>
<title>Anonymous CVS</title>
<step>
<para>
You will need a local copy of <productname>CVS</productname> (Concurrent Version Control
System), which you can get from
<ulink url="http://www.cyclic.com/">http://www.cyclic.com/</ulink> or
any GNU software archive site.
We currently recommend version 1.10 (the most recent at the time of writing).
</para>
</step>
<step>
<para>
Do an initial login to the <productname>CVS</productname> server:
<programlisting>
cvs -d :pserver:anoncvs@postgresql.org:/usr/local/cvsroot login
</programlisting>
You will be prompted for a password; enter '<literal>postgresql</literal>'.
You should only need to do this once, since the password will be
saved in <literal>.cvspass</literal> in your home directory.
</para>
</step>
<step>
<para>
Fetch the <productname>Postgres</productname> sources:
<programlisting>
</programlisting>
while inside of it, the patch is applied to the branch and
<emphasis>only</emphasis> the branch.
</para>
</sect1>
<sect1>
<title>Getting The Source Via Anonymous <productname>CVS</productname></title>
<para>
If you would like to keep up with the current sources on a regular
basis, you can fetch them from our <productname>CVS</productname> server
and then use <productname>CVS</productname> to
retrieve updates from time to time.
</para>
<procedure>
<title>Anonymous CVS</title>
<step>
<para>
You will need a local copy of <productname>CVS</productname>
(Concurrent Version Control System), which you can get from
<ulink url="http://www.cyclic.com/">http://www.cyclic.com/</ulink> or
any GNU software archive site.
We currently recommend version 1.10 (the most recent at the time
of writing). Many systems have a recent version of
<application>cvs</application> installed by default.
</para>
</step>
<step>
<para>
Do an initial login to the <productname>CVS</productname> server:
<programlisting>
$ cvs -d :pserver:anoncvs@postgresql.org:/usr/local/cvsroot login
</programlisting>
You will be prompted for a password; enter '<literal>postgresql</literal>'.
You should only need to do this once, since the password will be
saved in <literal>.cvspass</literal> in your home directory.
</para>
</step>
<step>
<para>
Fetch the <productname>Postgres</productname> sources:
<programlisting>
cvs -z3 -d :pserver:anoncvs@postgresql.org:/usr/local/cvsroot co -P pgsql
</programlisting>
which installs the <productname>Postgres</productname> sources into a
subdirectory <filename>pgsql</filename>
of the directory you are currently in.
<note>
<para>
If you have a fast link to the Internet, you may not need <option>-z3</option>,
which instructs <productname>CVS</productname> to use gzip compression for transferred data. But
on a modem-speed link, it's a very substantial win.
</para>
</note>
<para>
This initial checkout is a little slower than simply downloading
a <filename>tar.gz</filename> file; expect it to take 40 minutes or so if you
have a 28.8K modem. The advantage of <productname>CVS</productname> doesn't show up until you
want to update the file set later on.
</para>
</step>
<step>
<para>
Whenever you want to update to the latest <productname>CVS</productname> sources,
<command>cd</command> into
the <filename>pgsql</filename> subdirectory, and issue
<programlisting>
cvs -z3 update -d -P
</programlisting>
This will fetch only the changes since the last time you updated.
You can update in just a couple of minutes, typically, even over
a modem-speed line.
</para>
</step>
</programlisting>
which installs the <productname>Postgres</productname> sources into a
subdirectory <filename>pgsql</filename>
of the directory you are currently in.
<note>
<para>
If you have a fast link to the Internet, you may not need
<option>-z3</option>, which instructs
<productname>CVS</productname> to use gzip compression for transferred data. But
on a modem-speed link, it's a very substantial win.
</para>
</note>
</para>
<step>
<para>
You can save yourself some typing by making a file <filename>.cvsrc</filename>
in your home directory that contains
<para>
This initial checkout is a little slower than simply downloading
a <filename>tar.gz</filename> file; expect it to take 40 minutes or so if you
have a 28.8K modem. The advantage of
<productname>CVS</productname>
doesn't show up until you want to update the file set later on.
</para>
</step>
<step>
<para>
Whenever you want to update to the latest <productname>CVS</productname> sources,
<command>cd</command> into
the <filename>pgsql</filename> subdirectory, and issue
<programlisting>
$ cvs -z3 update -d -P
</programlisting>
This will fetch only the changes since the last time you updated.
You can update in just a couple of minutes, typically, even over
a modem-speed line.
</para>
</step>
<step>
<para>
You can save yourself some typing by making a file <filename>.cvsrc</filename>
in your home directory that contains
<programlisting>
<programlisting>
cvs -z3
update -d -P
</programlisting>
</programlisting>
This supplies the <option>-z3</option> option to all cvs commands, and the
<option>-d</option> and <option>-P</option> options to cvs update. Then you just have
to say
<programlisting>
$ cvs update
</programlisting>
to update your files.
</para>
</step>
</procedure>
<caution>
<para>
Some older versions of <productname>CVS</productname> have a bug that
causes all checked-out files to be stored world-writable in your
directory. If you see that this has happened, you can do something like
<programlisting>
$ chmod -R go-w pgsql
</programlisting>
to set the permissions properly.
This bug is fixed as of
<productname>CVS</productname> version 1.9.28.
</para>
</caution>
This supplies the <option>-z3</option> option to all cvs commands, and the
<option>-d</option> and <option>-P</option> options to cvs update. Then you just have
to say
<programlisting>
cvs update
</programlisting>
to update your files.
</para>
</step>
</procedure>
<para>
<caution>
Some older versions of <productname>CVS</productname> have a bug that
causes all checked-out files to be stored world-writable in your
directory. If you see that this has happened, you can do something like
<programlisting>
chmod -R go-w pgsql
</programlisting>
to set the permissions properly.
This bug is fixed as of <productname>CVS</productname> version 1.9.28.
</caution>
</para>
<para>
<productname>CVS</productname> can do a lot of other things, such as fetching prior revisions
of the <productname>Postgres</productname> sources rather than the latest development version.
For more info consult the manual that comes with <productname>CVS</productname>, or see the online
documentation at <ulink url="http://www.cyclic.com/">http://www.cyclic.com/</ulink>.
</para>
</sect1>
<sect1>
<title>Getting The Source Via <productname>CVSup</productname></title>
<para>
An alternative to using anonymous CVS for retrieving
the <productname>Postgres</productname> source tree
is <productname>CVSup</productname>. The major advantage to using
<productname>CVSup</productname> is that it can reliably
replicate the <emphasis>entire</emphasis> CVS repository on your local system,
allowing fast local access to cvs operations such as <option>log</option>
and <option>diff</option>. Other advantages include fast synchronization to
the <productname>Postgres</productname> server due to an efficient
streaming transfer protocol which only sends the changes since the last update.
</para>
<procedure>
<title>Installation from Binaries</title>
<para>
Instructions for installing <productname>CVSup</productname> from sources
are in a subsequent section. You can instead 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>,
or if you are running FreeBSD, for which <productname>CVSup</productname> is available
as a port.
</para>
<step>
<para>
Retrieve the binary tar file appropriate for your platform.
<substeps>
<step performance="optional">
<para>
If you are running FreeBSD, install the <productname>CVSup</productname> port.
</para>
</step>
<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>,
</para>
</step>
</substeps>
</para>
<step>
<para>
</para>
</procedure>
<sect2>
<title>Installation from Binaries</title>
<para>
Instructions for installing <productname>CVSup</productname> from sources
are in a subsequent section. If you have a platform for which static binaries
are posted on
<ulink url="ftp://postgresql.org/pub">the <productname>Postgres</productname> ftp site</ulink>.
</para>
<sect2>
<title>Client Configuration</title>
<para>
</para>
<sect2>
<title>Background</title>
<para>
<note>
<title>Author</title>
<para>
Written by <ulink url="mailto:jdp@polstra.com">John Polstra</ulink>, the
<productname>CVSup</productname> author.
</note>
Before you dismiss CVSup because of the language it's written in,
I hope you'll take a look at the long list of platforms supported
by the free DEC SRC Modula-3 compiler, at:
http://www.research.digital.com/SRC/modula-3/html/platforms.html
I developed CVSup using that compiler, under FreeBSD. I also have
reports from people who are using CVSup under Linux, Solaris, and
ALPHA/OSF. It should be easily portable to any of the POSIX systems
supported by the compiler.
I understand your reluctance to "change a winning team," but once
you've seen the speed increase of CVSup relative to sup, you'll no
longer view sup as "winning." Sup was the inspiration for me to
develop CVSup, precisely because it performs so badly in certain
situations.
Sup's synchronous request-ack communication pattern is death on a
high-latency network link. CVSup uses a streaming protocol that is
immune to latency problems. Its multi-threaded implementation
utilizes the network link in both directions simultaneously, at or
near its capacity.
If you are mirroring a CVS repository and add a tag to each file
(say, to make an official release), sup will send a fresh copy of
every file in the repository. CVSup sends only the tags, and edits
them into the files on the client host. It was just such a tagging
operation, and the attendent utter saturation of their server's
network link, that led the FreeBSD project to abandon sup in favor
of CVSup. If you ask on <FreeBSD-hackers@FreeBSD.ORG>, I'm sure
you'll get some opinions on whether CVSup is worth its Modula-3
hassle factor.
It's freeware. I don't get anything besides warm fuzzy feelings
when people use it. But I'd hate to see you rule it out simply
because of the language it's written in.
If I can answer any questions about CVSup or Modula-3, feel free
to contact me.
Best regards,
John Polstra
--
John Polstra jdp@polstra.com
John D. Polstra & Co., Inc. Seattle, Washington USA
"Self-knowledge is always bad news." -- John Barth
<sect2>
<title>Installing <productname>CVSup</productname></title>
<para>
Binary files of <productname>CVSup</productname> client executables compiled
for several platforms are posted on
<ulink url="ftp://postgresql.org/pub/CVSup">the PostgreSQL ftp site</ulink>.
In many cases, these binary files will be sufficient to get started with
<productname>CVSup</productname>.
</para>
<para>
Alternatively, you can install <productname>CVSup</productname> from
a FreeBSD package or from source. A clean installation from source code
requires installation of a <productname>Modula-3</productname> compiler,
which is also available as Linux <productname>RPM</productname>,
FreeBSD package, or source code.
<note>
<para>
A clean-source installation of Modula-3 takes roughly 200MB of disk space,
which shrinks to roughly 50MB of space when the sources are removed.
</note>
</para>
<sect3>
<title>Linux installation</title>
<para>
For a <productname>CVSup</productname> client, pick up the appropriate tarball
from <ulink url="ftp://postgresql.org/pub/CVSup">the PostgreSQL ftp site</ulink>.
Unpack the tarball into <filename>/usr/local/bin</filename>, then move the man page
file <filename>cvsup.1</filename> to <filename>/usr/local/man/man1</filename>.
</para>
<para>
To build <productname>CVSup</productname> from local sources,
pick up the <productname>Modula-3</productname>
distribution from
<ulink url="http://m3.polymtl.ca/m3">Polytechnique Montréal</ulink>,
who are actively maintaining the code base originally developed by
<ulink url="http://www.research.digital.com/SRC/modula-3/html/home.html">the DEC Systems Research Center</ulink>.
The <quote>PM3</quote> <productname>RPM</productname> distribution is roughly
30MB compressed.
</para>
From - Tue Dec 1 14:01:42 1998
Return-Path: <Thomas.G.Lockhart@jpl.nasa.gov>
Received: from eis-msg-012.jpl.nasa.gov ([137.78.68.42])
by eis-msg-002.jpl.nasa.gov (Netscape Mail Server v2.02)
with ESMTP id ADD868 for <tlockhar@mail1.jpl.nasa.gov>;
Mon, 21 Jul 1997 11:44:48 -0700
Return-Path: <tgl@mythos>
Received: from mythos.jpl.nasa.gov by eis-msg-012.jpl.nasa.gov; Mon, 21 Jul 1997 11:44:50 -0700
Received: by mythos.jpl.nasa.gov (5.65v3.2/1.1.10.5/11Jan97-0348AM)
id AA24680; Mon, 21 Jul 1997 18:45:05 GMT
Received: from pyros.jpl.nasa.gov by mythos.jpl.nasa.gov (5.65v3.2/1.1.10.5/11Jan97-0348AM)
id AA26520; Mon, 21 Jul 1997 18:44:59 GMT
Received: from eis-msg-012.jpl.nasa.gov by pyros.jpl.nasa.gov (5.65v3.2/1.1.8.2/15Aug95-1038PM)
id AA26023; Mon, 21 Jul 1997 18:44:59 GMT
Received: from austin.polstra.com by eis-msg-012.jpl.nasa.gov with ESMTP; Mon, 21 Jul 1997 11:44:40 -0700
Received: from austin.polstra.com (jdp@localhost)
by austin.polstra.com (8.8.6/8.8.5) with ESMTP id LAA00444
for <Thomas.Lockhart@jpl.nasa.gov>; Mon, 21 Jul 1997 11:44:47 -0700 (PDT)
Message-Id: <199707211844.LAA00444@austin.polstra.com>
To: "Thomas G. Lockhart" <Thomas.G.Lockhart@jpl.nasa.gov>
Subject: Re: [HACKERS] Re: CVSup is in Modula-3
In-Reply-To: Your message of "Mon, 21 Jul 1997 16:31:17 -0000."
<33D38ED5.132C8923@jpl.nasa.gov>
References: <199705210339.UAA13067@austin.polstra.com>
<33D38ED5.132C8923@jpl.nasa.gov>
Date: Mon, 21 Jul 1997 11:44:47 -0700
From: John Polstra <jdp@polstra.com>
X-Mozilla-Status: 0011
Content-Length: 1113
<para>
<productname>CVS</productname> can do a lot of other things,
such as fetching prior revisions
of the <productname>Postgres</productname> sources
rather than the latest development version.
For more info consult the manual that comes with
<productname>CVS</productname>, or see the online
documentation at
<ulink url="http://www.cyclic.com/">http://www.cyclic.com/</ulink>.
</para>
</sect1>
Tom,
<sect1>
<title>Getting The Source Via <productname>CVSup</productname></title>
> We are starting to try to set up CVSup to support the PostgreSQL
> project.
<para>
An alternative to using anonymous CVS for retrieving
the <productname>Postgres</productname> source tree
is <productname>CVSup</productname>.
<productname>CVSup</productname> was developed by
<ulink url="mailto:jdp@polstra.com">John Polstra</ulink> to
distribute CVS repositories and other file trees for
<ulink url="http://www.freebsd.org">the FreeBSD project</ulink>.
</para>
Great! If I can help, just let me know.
<para>
A major advantage to using
<productname>CVSup</productname> is that it can reliably
replicate the <emphasis>entire</emphasis> CVS repository on your local system,
allowing fast local access to cvs operations such as <option>log</option>
and <option>diff</option>. Other advantages include fast synchronization to
the <productname>Postgres</productname> server due to an efficient
streaming transfer protocol which only sends the changes since the last update.
</para>
> After being delayed while buying more disk to install Modula-3,
<sect2>
<title>Preparing A <productname>CVSup</productname> Client System</title>
<para>
Two directory areas are required for <productname>CVSup</productname>
to do it's job: a local <productname>CVS</productname> repository
(or simply a directory area if you are fetching a snapshot rather
than a repository; see below)
and a local <productname>CVSup</productname> bookkeeping
area. These can coexist in the same directory tree.
</para>
<para>
Decide where you want to keep your local copy of the
<productname>CVS</productname> repository. On one of our systems we
recently set up a repository in <filename>/home/cvs/</filename>,
but had formerly kept it under a
<productname>Postgres</productname> development tree in
<filename>/opt/postgres/cvs/</filename>. If you intend to keep your
repository in <filename>/home/cvs/</filename>, then put
<programlisting>
setenv CVSROOT /home/cvs
</programlisting>
in your <filename>.cshrc</filename> file, or a similar line in
your <filename>.bashrc</filename> or
<filename>.profile</filename> file, depending on your shell.
</para>
<para>
The <application>cvs</application> repository area must be initialized.
Once <envar>CVSROOT</envar> is set, then this can be done with a
single command:
<programlisting>
$ cvs init
</programlisting>
after which you should see at least a directory named
<filename>CVSROOT</filename> when listing the
<envar>CVSROOT</envar> directory:
<programlisting>
$ ls $CVSROOT
CVSROOT/
</programlisting>
</para>
</sect2>
<sect2>
<title>Running a <productname>CVSup</productname> Client</title>
<para>
Verify that
<application>cvsup</application> is in your path; on most systems
you can do this by typing
<programlisting>
which cvsup
</programlisting>
Then, simply run
<application>cvsup</application> using:
<programlisting>
$ cvsup -L 2 <replaceable class="parameter">postgres.cvsup</replaceable>
</programlisting>
where <option>-L 2</option> enables some status messages so you
can monitor the progress of the update,
and <replaceable class="parameter">postgres.cvsup</replaceable> is
the path and name you have given to your
<productname>CVSup</productname> configuration file.
</para>
<para>
Here is a <productname>CVSup</productname> configuration file
modified for a specific installation, and which maintains a full
local <productname>CVS</productname> repository:
<programlisting>
# This file represents the standard CVSup distribution file
# for the PostgreSQL ORDBMS project
# Modified by lockhart@alumni.caltech.edu 1997-08-28
# - Point to my local snapshot source tree
# - Pull the full CVS repository, not just the latest snapshot
#
# Defaults that apply to all the collections
*default host=postgresql.org
*default compress
*default release=cvs
*default delete use-rel-suffix
# enable the following line to get the latest snapshot
#*default tag=.
# enable the following line to get whatever was specified above or by default
# at the date specified below
#*default date=97.08.29.00.00.00
:-}
# base directory points to where CVSup will store its 'bookmarks' file(s)
# will create subdirectory sup/
#*default base=/opt/postgres # /usr/local/pgsql
*default base=/home/cvs
> I started back up on trying the installation. I have gotten the
> CVSup source distribution cvsup-15.1.tar.gz from www.cdrom.com and
> have m3 on my system, which already had zlib.
>
> There appears to be more needed on my RedHat Linux box; make fails
> with a syntax error on the last line of the Makefile which is
>
> .include <bsd.subdir.mk>
>
> I assume this is a FreeBSDism
# prefix directory points to where CVSup will store the actual distribution(s)
*default prefix=/home/cvs
Yes, sorry, the Makefiles aren't portable yet. It's easy to build
it by hand though. Chdir into each of the following directories in
the given order, and in each one type "m3build":
# complete distribution, including all below
pgsql
suptcp
suplib
server
client
# individual distributions vs 'the whole thing'
# pgsql-doc
# pgsql-perl5
# pgsql-src
If all goes well, the executables will get created in the
subdirectories "server/LINUXELF" and "client/LINUXELF".
</programlisting>
</para>
If you run into any portability problems, please let me know and
I'll try to send you patches right away. It's the only way I know
of to improve the portability of the package.
<para>
The following is a suggested <productname>CVSup</productname> config file from
<ulink url="ftp://ftp.postgresql.org/pub/CVSup/README.cvsup">the Postgres ftp site</ulink>
which will fetch the current snapshot only:
John
<programlisting>
# This file represents the standard CVSup distribution file
# for the PostgreSQL ORDBMS project
#
# Defaults that apply to all the collections
*default host=postgresql.org
*default compress
*default release=cvs
*default delete use-rel-suffix
*default tag=.
From - Tue Dec 1 14:02:37 1998
Return-Path: <Thomas.G.Lockhart@jpl.nasa.gov>
Received: from eis-msg-012.jpl.nasa.gov ([137.78.68.42])
by eis-msg-002.jpl.nasa.gov (Netscape Mail Server v2.02)
with ESMTP id ADT23584 for <tlockhar@mail1.jpl.nasa.gov>;
Mon, 21 Jul 1997 22:23:30 -0700
Return-Path: <tgl@mythos>
Received: from mythos.jpl.nasa.gov by eis-msg-012.jpl.nasa.gov; Mon, 21 Jul 1997 22:23:30 -0700
Received: by mythos.jpl.nasa.gov (5.65v3.2/1.1.10.5/11Jan97-0348AM)
id AA27710; Tue, 22 Jul 1997 05:23:46 GMT
Received: from pyros.jpl.nasa.gov by mythos.jpl.nasa.gov (5.65v3.2/1.1.10.5/11Jan97-0348AM)
id AA27627; Tue, 22 Jul 1997 05:23:45 GMT
Received: from eis-msg-012.jpl.nasa.gov by pyros.jpl.nasa.gov (5.65v3.2/1.1.8.2/15Aug95-1038PM)
id AA16826; Tue, 22 Jul 1997 05:23:44 GMT
Received: from austin.polstra.com by eis-msg-012.jpl.nasa.gov with ESMTP; Mon, 21 Jul 1997 22:22:24 -0700
Received: from austin.polstra.com (jdp@localhost)
by austin.polstra.com (8.8.6/8.8.5) with ESMTP id WAA04594
for <Thomas.Lockhart@jpl.nasa.gov>; Mon, 21 Jul 1997 22:22:40 -0700 (PDT)
Message-Id: <199707220522.WAA04594@austin.polstra.com>
To: "Thomas G. Lockhart" <Thomas.G.Lockhart@jpl.nasa.gov>
Subject: Re: [HACKERS] Re: CVSup is in Modula-3
In-Reply-To: Your message of "Tue, 22 Jul 1997 04:55:24 -0000."
<33D43D3C.65F75F5@jpl.nasa.gov>
References: <199705210339.UAA13067@austin.polstra.com> <33D38ED5.132C8923@jpl.nasa.gov> <199707211844.LAA00444@austin.polstra.com> <33D409F9.5FEF02C7@jpl.nasa.gov> <199707220156.SAA03432@austin.polstra.com>
<33D43D3C.65F75F5@jpl.nasa.gov>
Date: Mon, 21 Jul 1997 22:22:40 -0700
From: John Polstra <jdp@polstra.com>
X-Mozilla-Status: 0011
Content-Length: 2890
# base directory points to where CVSup will store its 'bookmarks' file(s)
*default base=<replaceable class="parameter">/usr/local/pgsql</replaceable>
# prefix directory points to where CVSup will store the actual distribution(s)
*default prefix=<replaceable class="parameter">/usr/local/pgsql</replaceable>
# complete distribution, including all below
pgsql
# individual distributions vs 'the whole thing'
# pgsql-doc
# pgsql-perl5
# pgsql-src
</programlisting>
</para>
</sect2>
<sect2>
<title>Installing <productname>CVSup</productname></title>
<para>
<productname>CVSup</productname> is available as source, pre-built
binaries, or Linux RPMs. It is far easier to use a binary than to
build from source, primarily because the very capable, but
voluminous, Modula-3 compiler is required for the build.
</para>
<procedure>
<title><productname>CVSup</productname> Installation from Binaries</title>
<para>
You can instead 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>,
or if you are running FreeBSD, for which
<productname>CVSup</productname> is available as a port.
<note>
<para>
<productname>CVSup</productname> was originally developed as a
tool for distributing the <productname>FreeBSD</productname>
source tree. It is available as a "port", and for those running
FreeBSD, if this is not sufficient to tell how to obtain and
install it then please contribute a procedure here.
</para>
</note>
</para>
<para>
At the time of writing, binaries are available for
Alpha/Tru64, ix86/xBSD,
HPPA/HPUX-10.20, and MIPS/irix.
ix86/linux-libc5, ix86/linux-glibc,
Sparc/Solaris, and Sparc/SunOS.
</para>
<step>
<para>
Retrieve the binary tar file for
<application>cvsup</application>
(<application>cvsupd</application> is not required
to be a client) appropriate for your platform.
</para>
<substeps>
<step performance="optional">
<para>
If you are running FreeBSD, install the <productname>CVSup</productname> port.
</para>
</step>
<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>,
</para>
</step>
</substeps>
</step>
<step>
<para>
Check the tar file to verify the contents and directory
structure, if any. For the linux tar file at least, the static binary
and man page is included without any directory packaging.
</para>
<substeps>
<step>
<para>
If the binary is in the top level of the tar file, then simply
unpack the tar file into your target directory:
<programlisting>
$ cd /usr/local/bin
$ tar zxvf /usr/local/src/cvsup-16.0-linux-i386.tar.gz
$ mv cvsup.1 ../doc/man/man1/
</programlisting>
</para>
</step>
<step>
<para>
If there is a directory structure in the tar file, then unpack
the tar file within /usr/local/src and move the binaries into
the appropriate location as above.
</para>
</step>
</substeps>
</step>
<step>
<para>
Ensure that the new binaries are in your path.
<programlisting>
$ rehash
$ which cvsup
$ set path=(<replaceable>path to cvsup</replaceable> $path)
$ which cvsup
/usr/local/bin/cvsup
</programlisting>
</para>
</step>
</procedure>
</sect2>
<sect2>
<title>Installation from Sources</title>
<para>
Installing <productname>CVSup</productname> from sources is not
entirely trivial, primarily because most systems will need to
install a Modula-3 compiler first.
This compiler is available as Linux <productname>RPM</productname>,
FreeBSD package, or source code.
<note>
<para>
A clean-source installation of Modula-3 takes roughly 200MB of disk space,
which shrinks to roughly 50MB of space when the sources are removed.</para>
</note>
</para>
<procedure>
<title>Linux installation</title>
<step>
<para>
Install Modula-3.
</para>
<substeps>
<step>
<para>
Pick up the <productname>Modula-3</productname>
distribution from
<ulink url="http://m3.polymtl.ca/m3">Polytechnique Montréal</ulink>,
who are actively maintaining the code base originally developed by
<ulink
url="http://www.research.digital.com/SRC/modula-3/html/home.html">the DEC Systems Research Center</ulink>.
The <quote>PM3</quote> <productname>RPM</productname> distribution is roughly
30MB compressed. At the time of writing, the 1.1.10-1 release
installed cleanly on RH-5.2, whereas the 1.1.11-1 release is
apparently built for another release (RH-6.0?) and does not run on RH-5.2.
<tip>
<para>
This particular rpm packaging has
<emphasis>many</emphasis> <productname>RPM</productname> files,
so you will likely want to place them into a separate
directory.
</para>
</tip>
</para>
</step>
<step>
<para>
Install the Modula-3 rpms:
<programlisting>
# rpm -Uvh pm3*.rpm
</programlisting>
</para>
</step>
</substeps>
</step>
<step>
<para>
Unpack the cvsup distribution:
<programlisting>
# cd /usr/local/src
# tar zxf cvsup-16.0.tar.gz
</programlisting>
</para>
</step>
<step>
<para>
Build the cvsup distribution, suppressing the GUI interface
feature to avoid requiring X11 libraries:
<programlisting>
# make M3FLAGS="-DNOGUI"
</programlisting>
and if you want to build a static binary to move to systems
which may not have Modula-3 installed, try:
<programlisting>
# make M3FLAGS="-DNOGUI -DSTATIC"
</programlisting>
</para>
</step>
<step>
<para>
Install the built binary:
<programlisting>
# make M3FLAGS="-DNOGUI -DSTATIC" install
</programlisting>
</para>
</step>
</procedure>
</sect2>
</sect1>
</appendix>
<!--
> It became clear that I had a problem with my m3 installation; some
> X11 libraries were not being found correctly.
......@@ -615,7 +762,8 @@ If you are on a T1 or better, you should probably delete the
As shown, it will get the repository (RCS) files. If you uncomment
the line containing "tag=." then it will instead check out the
latest version of each file. There's a bunch more information about
what you can do at <http://www.freebsd.org/handbook/cvsup.html>.
what you can do in
<ulink url="http://www.freebsd.org/handbook/cvsup.html">the CVSup Handbook</ulink>.
There is one other thing I want to send you, but not tonight. I
discovered the hard way that you need a malloc package that is
......@@ -643,46 +791,12 @@ Great! I'll do my best to help make sure you don't regret it.
John
From - Tue Dec 1 14:03:48 1998
Return-Path: <Thomas.G.Lockhart@jpl.nasa.gov>
Received: from eis-msg-012.jpl.nasa.gov ([137.78.68.42])
by eis-msg-002.jpl.nasa.gov (Netscape Mail Server v2.02)
with ESMTP id AAK25400 for <tlockhar@mail1.jpl.nasa.gov>;
Mon, 28 Jul 1997 11:08:12 -0700
Return-Path: <tgl@mythos>
Received: from mythos.jpl.nasa.gov by eis-msg-012.jpl.nasa.gov; Mon, 28 Jul 1997 11:08:07 -0700
Received: by mythos.jpl.nasa.gov (5.65v3.2/1.1.10.5/11Jan97-0348AM)
id AA09109; Mon, 28 Jul 1997 18:08:30 GMT
Date: Mon, 28 Jul 1997 18:08:30 GMT
From: Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
Message-Id: <9707281808.AA09109@mythos.jpl.nasa.gov>
Subject: Thread safe malloc for Modula-3
To: tlockhar@mail1.jpl.nasa.gov
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Md5: kDq1byZn+NpMUrFlhA9EhA==
X-Mozilla-Status: 0001
Content-Length: 27233
------------- Begin Forwarded Message -------------
>From jdp@austin.polstra.com Sat Jul 26 03:42:04 1997
To: "Thomas G. Lockhart" <Thomas.G.Lockhart@jpl.nasa.gov>
Subject: Thread safe malloc for Modula-3
Date: Fri, 25 Jul 1997 20:41:41 -0700
From: John Polstra <jdp@polstra.com>
Content-Length: 26878
Tom,
I'm appending the sources for the thread safe version of malloc that
I told you about. I believe that it will simply compile and work
under Linux, but I've never had an opportunity to test it there.
I urge you to put it into your Modula-3 system -- otherwise, you
I urge you to put it into your Modula-3 system; otherwise, you
are guaranteed to get occasional mysterious core dumps from cvsupd.
As a first step, I'd suggest simply trying to compile it under
......@@ -720,38 +834,6 @@ using even aside from the thread safety of it.
Regards,
John
From - Tue Dec 1 14:04:30 1998
Received: from eis-msg-012.jpl.nasa.gov (eis-msg-012.jpl.nasa.gov [137.78.68.42]) by alumnae.caltech.edu (8.8.3/8.7.3) with ESMTP id WAA24486 for <lockhart@alumni.caltech.edu>; Tue, 29 Jul 1997 22:54:06 -0700 (PDT)
Received: from mythos.jpl.nasa.gov by eis-msg-012.jpl.nasa.gov; Tue, 29 Jul 1997 22:53:32 -0700
Received: by mythos.jpl.nasa.gov (5.65v3.2/1.1.10.5/11Jan97-0348AM)
id AA13731; Wed, 30 Jul 1997 05:54:08 GMT
Received: from hub.org by mythos.jpl.nasa.gov (5.65v3.2/1.1.10.5/11Jan97-0348AM)
id AA13687; Wed, 30 Jul 1997 05:54:07 GMT
Received: from localhost (majordom@localhost) by hub.org (8.8.5/8.7.5) with SMTP id BAA07442; Wed, 30 Jul 1997 01:52:26 -0400 (EDT)
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Wed, 30 Jul 1997 01:48:16 -0400 (EDT)
Received: (from majordom@localhost) by hub.org (8.8.5/8.7.5) id BAA07304 for pgsql-hackers-outgoing; Wed, 30 Jul 1997 01:48:03 -0400 (EDT)
Received: from golem.jpl.nasa.gov (root@gnet04.jpl.nasa.gov [128.149.70.168]) by hub.org (8.8.5/8.7.5) with ESMTP id BAA07297 for <hackers@postgresql.org>; Wed, 30 Jul 1997 01:47:55 -0400 (EDT)
Received: from golem (localhost [127.0.0.1])
by golem.jpl.nasa.gov (8.8.5/8.8.5) with SMTP id FAA23412;
Wed, 30 Jul 1997 05:46:58 GMT
Message-Id: <33DED551.7F31C751@alumni.caltech.edu>
Date: Wed, 30 Jul 1997 05:46:58 +0000
From: "Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Organization: Caltech/JPL
X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.30 i686)
Mime-Version: 1.0
To: The Hermit Hacker <scrappy@hub.org>
Cc: hackers@postgresql.org, John Polstra <jdp@polstra.com>
Subject: [HACKERS] cvsup
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@hub.org
Precedence: bulk
Content-Type: text/plain; charset=us-ascii
X-Mozilla-Status: 0001
Content-Length: 1069
I've deposited a statically built cvsup client executable (and man pages
and test configuration) in
......@@ -780,41 +862,6 @@ Thanks to John for getting me going.
- Tom
From - Tue Dec 1 14:07:28 1998
Received: from eis-msg-012.jpl.nasa.gov (eis-msg-012.jpl.nasa.gov [137.78.68.42]) by alumnae.caltech.edu (8.8.3/8.7.3) with ESMTP id XAA25148 for <lockhart@alumni.caltech.edu>; Tue, 29 Jul 1997 23:17:22 -0700 (PDT)
Received: from mythos.jpl.nasa.gov by eis-msg-012.jpl.nasa.gov; Tue, 29 Jul 1997 23:16:48 -0700
Received: by mythos.jpl.nasa.gov (5.65v3.2/1.1.10.5/11Jan97-0348AM)
id AA09663; Wed, 30 Jul 1997 06:17:25 GMT
Received: from hub.org by mythos.jpl.nasa.gov (5.65v3.2/1.1.10.5/11Jan97-0348AM)
id AA13538; Wed, 30 Jul 1997 06:17:24 GMT
Received: from localhost (majordom@localhost) by hub.org (8.8.5/8.7.5) with SMTP id CAA08702; Wed, 30 Jul 1997 02:14:29 -0400 (EDT)
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Wed, 30 Jul 1997 02:03:54 -0400 (EDT)
Received: (from majordom@localhost) by hub.org (8.8.5/8.7.5) id CAA08094 for pgsql-hackers-outgoing; Wed, 30 Jul 1997 02:03:41 -0400 (EDT)
Received: from golem.jpl.nasa.gov (root@gnet04.jpl.nasa.gov [128.149.70.168]) by hub.org (8.8.5/8.7.5) with ESMTP id CAA08086 for <hackers@postgreSQL.org>; Wed, 30 Jul 1997 02:03:10 -0400 (EDT)
Received: from golem (localhost [127.0.0.1])
by golem.jpl.nasa.gov (8.8.5/8.8.5) with SMTP id GAA23505;
Wed, 30 Jul 1997 06:02:40 GMT
Message-Id: <33DED900.4EEA0E9F@alumni.caltech.edu>
Date: Wed, 30 Jul 1997 06:02:40 +0000
From: "Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Organization: Caltech/JPL
X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.30 i686)
Mime-Version: 1.0
To: The Hermit Hacker <scrappy@hub.org>
Cc: hackers@postgresql.org
Subject: [Fwd: Re: [HACKERS] Re: CVSup is in Modula-3]
Sender: owner-hackers@hub.org
Precedence: bulk
Content-Type: multipart/mixed; boundary="------------524572433268691C62FDF4"
X-Mozilla-Status: 0001
Content-Length: 38655
This is a multi-part message in MIME format.
--------------524572433268691C62FDF4
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
For the thread-safe malloc, do the following:
1) install Modula-3
2) add the enclosed file "malloc.c" to m3/m3core/src/runtime/LINUXELF
......@@ -822,7 +869,7 @@ For the thread-safe malloc, do the following:
c_source ("malloc")
4) do an "m3build" and an m3ship from the appropriate directory.
>From what John said, the malloc problem can be noticable for the
From what John said, the malloc problem can be noticable for the
server-side running cvsupd. Clients may not need it.
Unfortunately I seem to have lost John's original good instructions for
......@@ -831,365 +878,7 @@ instructions again...
- Tom
--------------524572433268691C62FDF4
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Return-Path: <Thomas.G.Lockhart@jpl.nasa.gov>
Received: from eis-msg-012.jpl.nasa.gov ([137.78.68.42])
by eis-msg-002.jpl.nasa.gov (Netscape Mail Server v2.02)
with ESMTP id ADD868 for <tlockhar@mail1.jpl.nasa.gov>;
Mon, 21 Jul 1997 11:44:48 -0700
Return-Path: <tgl@mythos>
Received: from mythos.jpl.nasa.gov by eis-msg-012.jpl.nasa.gov; Mon, 21 Jul 1997 11:44:50 -0700
Received: by mythos.jpl.nasa.gov (5.65v3.2/1.1.10.5/11Jan97-0348AM)
id AA24680; Mon, 21 Jul 1997 18:45:05 GMT
Received: from pyros.jpl.nasa.gov by mythos.jpl.nasa.gov (5.65v3.2/1.1.10.5/11Jan97-0348AM)
id AA26520; Mon, 21 Jul 1997 18:44:59 GMT
Received: from eis-msg-012.jpl.nasa.gov by pyros.jpl.nasa.gov (5.65v3.2/1.1.8.2/15Aug95-1038PM)
id AA26023; Mon, 21 Jul 1997 18:44:59 GMT
Received: from austin.polstra.com by eis-msg-012.jpl.nasa.gov with ESMTP; Mon, 21 Jul 1997 11:44:40 -0700
Received: from austin.polstra.com (jdp@localhost)
by austin.polstra.com (8.8.6/8.8.5) with ESMTP id LAA00444
for <Thomas.Lockhart@jpl.nasa.gov>; Mon, 21 Jul 1997 11:44:47 -0700 (PDT)
Message-Id: <199707211844.LAA00444@austin.polstra.com>
To: "Thomas G. Lockhart" <Thomas.G.Lockhart@jpl.nasa.gov>
Subject: Re: [HACKERS] Re: CVSup is in Modula-3
In-Reply-To: Your message of "Mon, 21 Jul 1997 16:31:17 -0000."
<33D38ED5.132C8923@jpl.nasa.gov>
References: <199705210339.UAA13067@austin.polstra.com>
<33D38ED5.132C8923@jpl.nasa.gov>
Date: Mon, 21 Jul 1997 11:44:47 -0700
From: John Polstra <jdp@polstra.com>
Tom,
> We are starting to try to set up CVSup to support the PostgreSQL
> project.
Great! If I can help, just let me know.
> After being delayed while buying more disk to install Modula-3,
:-}
> I started back up on trying the installation. I have gotten the
> CVSup source distribution cvsup-15.1.tar.gz from www.cdrom.com and
> have m3 on my system, which already had zlib.
>
> There appears to be more needed on my RedHat Linux box; make fails
> with a syntax error on the last line of the Makefile which is
>
> .include <bsd.subdir.mk>
>
> I assume this is a FreeBSDism
Yes, sorry, the Makefiles aren't portable yet. It's easy to build
it by hand though. Chdir into each of the following directories in
the given order, and in each one type "m3build":
suptcp
suplib
server
client
If all goes well, the executables will get created in the
subdirectories "server/LINUXELF" and "client/LINUXELF".
If you run into any portability problems, please let me know and
I'll try to send you patches right away. It's the only way I know
of to improve the portability of the package.
John
--------------524572433268691C62FDF4
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Return-Path: <Thomas.G.Lockhart@jpl.nasa.gov>
Received: from eis-msg-012.jpl.nasa.gov ([137.78.68.42])
by eis-msg-002.jpl.nasa.gov (Netscape Mail Server v2.02)
with ESMTP id ABJ29576 for <tlockhar@mail1.jpl.nasa.gov>;
Mon, 21 Jul 1997 18:31:59 -0700
Return-Path: <tgl@mythos>
Received: from mythos.jpl.nasa.gov by eis-msg-012.jpl.nasa.gov; Mon, 21 Jul 1997 18:32:01 -0700
Received: by mythos.jpl.nasa.gov (5.65v3.2/1.1.10.5/11Jan97-0348AM)
id AA27435; Tue, 22 Jul 1997 01:32:15 GMT
Received: from pyros.jpl.nasa.gov by mythos.jpl.nasa.gov (5.65v3.2/1.1.10.5/11Jan97-0348AM)
id AA27371; Tue, 22 Jul 1997 01:31:15 GMT
Received: from eis-msg-012.jpl.nasa.gov by pyros.jpl.nasa.gov (5.65v3.2/1.1.8.2/15Aug95-1038PM)
id AA07056; Tue, 22 Jul 1997 01:31:14 GMT
Received: from austin.polstra.com by eis-msg-012.jpl.nasa.gov with ESMTP; Mon, 21 Jul 1997 18:30:52 -0700
Received: from austin.polstra.com (jdp@localhost)
by austin.polstra.com (8.8.6/8.8.5) with ESMTP id SAA03293
for <Thomas.Lockhart@jpl.nasa.gov>; Mon, 21 Jul 1997 18:31:05 -0700 (PDT)
Message-Id: <199707220131.SAA03293@austin.polstra.com>
To: "Thomas G. Lockhart" <Thomas.G.Lockhart@jpl.nasa.gov>
Subject: Re: [HACKERS] Re: CVSup is in Modula-3
In-Reply-To: Your message of "Tue, 22 Jul 1997 01:16:41 -0000."
<33D409F9.5FEF02C7@jpl.nasa.gov>
References: <199705210339.UAA13067@austin.polstra.com> <33D38ED5.132C8923@jpl.nasa.gov> <199707211844.LAA00444@austin.polstra.com>
<33D409F9.5FEF02C7@jpl.nasa.gov>
Date: Mon, 21 Jul 1997 18:31:05 -0700
From: John Polstra <jdp@polstra.com>
> > suplib
>
> Changed fnmatch.h to subvert the #ifndef _POSIX_SOURCE, since
> FNM_LEADING_DIR and the others are not apparently defined on my RedHat
> Linux/v4.2 system.
OK, I'll check that and try to make it more portable.
> new source -> compiling ../src/FileAttr.m3
> "../src/FileAttr.m3", line 609: LOOPHOLE: expression's size differs from
> type's
> "../src/FileAttr.m3", line 610: LOOPHOLE: expression's size differs from
> type's
I'll have to think about the best way to make that portable. For
now, edit "suplib/src/FileAttr.m3". In each of lines 609 and 610,
change the "-1" to "65535". That should allow you to proceed.
I'm 99% sure that all the subsequent error messages were caused by
the failure of this file to compile. It just might work after this
... :-)
BTW, it has been used by several people under Linux. But
FileAttr.m3 is a new file for this release, so it hasn't had the
portability bugs ironed out yet.
Regards,
John
--------------524572433268691C62FDF4
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Return-Path: <Thomas.G.Lockhart@jpl.nasa.gov>
Received: from eis-msg-012.jpl.nasa.gov ([137.78.68.42])
by eis-msg-002.jpl.nasa.gov (Netscape Mail Server v2.02)
with ESMTP id ABJ530 for <tlockhar@mail1.jpl.nasa.gov>;
Mon, 21 Jul 1997 18:56:46 -0700
Return-Path: <tgl@mythos>
Received: from mythos.jpl.nasa.gov by eis-msg-012.jpl.nasa.gov; Mon, 21 Jul 1997 18:56:47 -0700
Received: by mythos.jpl.nasa.gov (5.65v3.2/1.1.10.5/11Jan97-0348AM)
id AA27403; Tue, 22 Jul 1997 01:57:02 GMT
Received: from pyros.jpl.nasa.gov by mythos.jpl.nasa.gov (5.65v3.2/1.1.10.5/11Jan97-0348AM)
id AA27419; Tue, 22 Jul 1997 01:57:01 GMT
Received: from eis-msg-012.jpl.nasa.gov by pyros.jpl.nasa.gov (5.65v3.2/1.1.8.2/15Aug95-1038PM)
id AA22933; Tue, 22 Jul 1997 01:57:00 GMT
Received: from austin.polstra.com by eis-msg-012.jpl.nasa.gov with ESMTP; Mon, 21 Jul 1997 18:56:43 -0700
Received: from austin.polstra.com (jdp@localhost)
by austin.polstra.com (8.8.6/8.8.5) with ESMTP id SAA03432
for <Thomas.Lockhart@jpl.nasa.gov>; Mon, 21 Jul 1997 18:56:57 -0700 (PDT)
Message-Id: <199707220156.SAA03432@austin.polstra.com>
To: "Thomas G. Lockhart" <Thomas.G.Lockhart@jpl.nasa.gov>
Subject: Re: [HACKERS] Re: CVSup is in Modula-3
In-Reply-To: Your message of "Tue, 22 Jul 1997 01:16:41 -0000."
<33D409F9.5FEF02C7@jpl.nasa.gov>
References: <199705210339.UAA13067@austin.polstra.com> <33D38ED5.132C8923@jpl.nasa.gov> <199707211844.LAA00444@austin.polstra.com>
<33D409F9.5FEF02C7@jpl.nasa.gov>
Date: Mon, 21 Jul 1997 18:56:57 -0700
From: John Polstra <jdp@polstra.com>
Erk. I just realized during dinner that the fix I sent you for
FileAttr.m3 probably won't work either. You'll probably get exactly
the same error messages as before.
Instead of what I told you before, just change those two lines to
this:
owner := 65535;
group := 65535;
I hope I caught you before you wasted too much time on it.
John
--------------524572433268691C62FDF4
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Return-Path: <Thomas.G.Lockhart@jpl.nasa.gov>
Received: from eis-msg-012.jpl.nasa.gov ([137.78.68.42])
by eis-msg-002.jpl.nasa.gov (Netscape Mail Server v2.02)
with ESMTP id ADT23584 for <tlockhar@mail1.jpl.nasa.gov>;
Mon, 21 Jul 1997 22:23:30 -0700
Return-Path: <tgl@mythos>
Received: from mythos.jpl.nasa.gov by eis-msg-012.jpl.nasa.gov; Mon, 21 Jul 1997 22:23:30 -0700
Received: by mythos.jpl.nasa.gov (5.65v3.2/1.1.10.5/11Jan97-0348AM)
id AA27710; Tue, 22 Jul 1997 05:23:46 GMT
Received: from pyros.jpl.nasa.gov by mythos.jpl.nasa.gov (5.65v3.2/1.1.10.5/11Jan97-0348AM)
id AA27627; Tue, 22 Jul 1997 05:23:45 GMT
Received: from eis-msg-012.jpl.nasa.gov by pyros.jpl.nasa.gov (5.65v3.2/1.1.8.2/15Aug95-1038PM)
id AA16826; Tue, 22 Jul 1997 05:23:44 GMT
Received: from austin.polstra.com by eis-msg-012.jpl.nasa.gov with ESMTP; Mon, 21 Jul 1997 22:22:24 -0700
Received: from austin.polstra.com (jdp@localhost)
by austin.polstra.com (8.8.6/8.8.5) with ESMTP id WAA04594
for <Thomas.Lockhart@jpl.nasa.gov>; Mon, 21 Jul 1997 22:22:40 -0700 (PDT)
Message-Id: <199707220522.WAA04594@austin.polstra.com>
To: "Thomas G. Lockhart" <Thomas.G.Lockhart@jpl.nasa.gov>
Subject: Re: [HACKERS] Re: CVSup is in Modula-3
In-Reply-To: Your message of "Tue, 22 Jul 1997 04:55:24 -0000."
<33D43D3C.65F75F5@jpl.nasa.gov>
References: <199705210339.UAA13067@austin.polstra.com> <33D38ED5.132C8923@jpl.nasa.gov> <199707211844.LAA00444@austin.polstra.com> <33D409F9.5FEF02C7@jpl.nasa.gov> <199707220156.SAA03432@austin.polstra.com>
<33D43D3C.65F75F5@jpl.nasa.gov>
Date: Mon, 21 Jul 1997 22:22:40 -0700
From: John Polstra <jdp@polstra.com>
> It became clear that I had a problem with my m3 installation; some
> X11 libraries were not being found correctly.
By the way, you can build the client without the GUI by doing this
in the "client" subdirectory:
m3build -DNOGUI
If you build it that way, then it doesn't need the X11 libraries and
it's quite a bit smaller. The GUI is fun to watch, but it's not
very useful. I originally implemented it because it made debugging
the multi-threaded client program much easier.
> Anyway, with the reinstall and the two-line patch above (and that
> one include-file _POSIX_SOURCE workaround from the previous try),
> things built cleanly.
Good!
> Now I just need a server somewhere to test.
If you want to try it out, there are public servers for the FreeBSD
source repository at cvsup.freebsd.org and cvsup2.freebsd.org.
Here's a suggested supfile:
*default host=cvsup.freebsd.org compress
*default release=cvs
*default base=/home/jdp/cvsup-test # FIX THIS
*default delete use-rel-suffix
# *default tag=.
src-bin
This will fetch you the source repository for the programs that get
installed into "/bin". I chose it because it's one of the smaller
pieces of the system. Make an empty directory someplace for
testing, and change the "FIX THIS" line to specify that directory
after the "base=".
If you are on a T1 or better, you should probably delete the
"compress" keyword in the first line.
As shown, it will get the repository (RCS) files. If you uncomment
the line containing "tag=." then it will instead check out the
latest version of each file. There's a bunch more information about
what you can do at <http://www.freebsd.org/handbook/cvsup.html>.
There is one other thing I want to send you, but not tonight. I
discovered the hard way that you need a malloc package that is
thread-safe with respect to the Modula-3 threads package. The
Modula-3 runtime takes care to do the proper mutual exclusion around
all calls it makes to malloc. But if you call certain functions in
the native C library which in turn call malloc, then the mutual
exclusion gets bypassed. This can lead to rare but baffling core
dumps.
For FreeBSD, I solved this by adding a thread-safe malloc package
into the Modula-3 runtime. The package is quite portable, and I'm
sure it will work well for Linux with very few changes (probably
none at all). I want to send it to you along with instructions
for making it a part of the "libm3core" library. It's very simple,
but I've run out of steam for tonight. :-) Once you have this
malloc in place, the CVSup system should be rock solid. We have
servers that have been up for weeks and have served many thousands
of clients without any observed problems.
> We hope to have the Postgres tree using CVSup within a month or
> so, and hope to retire sup in September...
Great! I'll do my best to help make sure you don't regret it.
John
From - Tue Dec 1 14:09:25 1998
Received: from eis-msg-012.jpl.nasa.gov (eis-msg-012.jpl.nasa.gov [137.78.68.42]) by alumnae.caltech.edu (8.8.3/8.7.3) with ESMTP id SAA17924 for <lockhart@alumni.caltech.edu>; Sat, 9 Aug 1997 18:34:20 -0700 (PDT)
Received: from mythos.jpl.nasa.gov by eis-msg-012.jpl.nasa.gov; Sat, 9 Aug 1997 18:33:19 -0700
Received: by mythos.jpl.nasa.gov (5.65v3.2/1.1.10.5/11Jan97-0348AM)
id AA29836; Sun, 10 Aug 1997 01:34:22 GMT
Received: from hub.org by mythos.jpl.nasa.gov (5.65v3.2/1.1.10.5/11Jan97-0348AM)
id AA28782; Sun, 10 Aug 1997 01:34:21 GMT
Received: from hub.org (hub.org [207.107.138.200]) by hub.org (8.8.5/8.7.5) with ESMTP id VAA13030; Sat, 9 Aug 1997 21:27:21 -0400 (EDT)
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Sat, 09 Aug 1997 21:23:11 -0400 (EDT)
Received: (from majordom@localhost) by hub.org (8.8.5/8.7.5) id VAA12661 for pgsql-hackers-outgoing; Sat, 9 Aug 1997 21:23:04 -0400 (EDT)
Received: from thelab.hub.org (root@ppp-164.halifax-01.ican.net [206.231.248.164]) by hub.org (8.8.5/8.7.5) with ESMTP id VAA12657 for <pgsql-hackers@postgresql.org>; Sat, 9 Aug 1997 21:22:54 -0400 (EDT)
Received: from thelab.hub.org (scrappy@localhost [127.0.0.1]) by thelab.hub.org (8.8.6/8.8.2) with SMTP id WAA05735 for <pgsql-hackers@postgresql.org>; Sat, 9 Aug 1997 22:22:27 -0300 (ADT)
Date: Sat, 9 Aug 1997 22:22:27 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
Subject: [HACKERS] CVSup ready for prime time...
Message-Id: <Pine.NEB.3.96.970809221034.4468L-100000@thelab.hub.org>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-hackers@hub.org
Precedence: bulk
X-Mozilla-Status: 0001
Content-Length: 1173
Wow...after several hours of playing with this, I believe I've finally
got the last kink worked out (thanks to John)...
The following is the CVSup config file that I'm using to grab the current
distribution...if anyone can find anything wrong with it, please let me
know:
===================
# This file represents the standard CVSup distribution file
# for the PostgreSQL ORDBMS project
#
# Defaults that apply to all the collections
*default host=postgresql.org
*default compress
*default release=cvs
*default delete use-rel-suffix
*default tag=.
# base directory points to where CVSup will store its 'bookmarks' file(s)
*default base=/usr/local/pgsql
# prefix directory points to where CVSup will store the actual distribution(s)
*default prefix=/usr/local/pgsql
# complete distribution, including all below
pgsql
# individual distributions vs 'the whole thing'
# pgsql-doc
# pgsql-perl5
# pgsql-src
===================
This file is also available at:
ftp.postgresql.org/pub/CVSup/README.cvsup
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
-->
<!-- Keep this comment at the end of the file
......
doc/src/sgml/datetime.sgml
View file @ 654f8f0b
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
Hi Thomas,
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.
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.
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
and this is why pope Gregory XIII in accordance with instructions
from the Council of Trent reformed the calendar to correct this error.
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.
The approximation 365+97/400 is achieved by having 97 leap years
every 400 years.
The Gregorian calendar has 97 leap years every 400 years:
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/datetime.sgml,v 2.2 1999/05/22 02:27:23 thomas Exp $
Date/time details
Every year divisible by 4 is a leap year.
However, every year divisible by 100 is not a leap year.
However, every year divisible by 400 is a leap year after all.
$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.
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.
<appendix label="UG1" id="datetime-append">
<title>Date/Time Support</title>
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.
<sect1>
<title>Time Zones</title>
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.
<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>
This is why unix has the cal 9 1752 like this:
September 1752
S M Tu W Th F S
1 2 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
<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>
<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>
My question is:
^^^^^^^^^^^^
<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>
If SQL92 says:
<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>
(Second Informal Review Draft) ISO/IEC 9075:1992, Database
Language SQL- July 30, 1992
<step>
<para>
Otherwise, interpret as a year.
</para>
</step>
</substeps>
</step>
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.
^^^^^^^^^^^^^^^
<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>
Dates between 1752-09-03 and 1752-09-13.
Are they valid dates?
^^^^^^^^^^^^^^^^
<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>
> 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.
<sect1>
<title>History</title>
People's Republic of China uses the Gregorian calendar
for civil purposes. Chinese calendar is used for determining
festivals.
<note>
<para>
Contributed by
<ulink url="jose@sferacarta.com">José Soares</ulink>.
</para>
</note>
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
<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.
By contrast, in the older Julian calendar only years divisible by 4 are leap years.
</para>
<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.
Thus 2 Sep 1752 was followed by 14 Sep 1752.
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
17 18 19 20 21 22 23
24 25 26 27 28 29 30
</programlisting>
</para>
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:
-->
doc/src/sgml/pg_options.sgml
View file @ 654f8f0b
<Chapter Id="pg-options">
<Chapter Id="pg-options-dev">
<DocInfo>
<AuthorGroup>
<Author>
......
doc/src/sgml/postgres.sgml
View file @ 654f8f0b
<!--
$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>
......
doc/src/sgml/programmer.sgml
View file @ 654f8f0b
<!--
$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;
......
doc/src/sgml/query.sgml
View file @ 654f8f0b
......@@ -158,9 +158,6 @@ COPY INTO weather FROM '/home/user/weather.txt'
</para>
</sect1>
</Para>
</sect1>
<Sect1>
<Title>Querying a Class</Title>
......
doc/src/sgml/sql.sgml
View file @ 654f8f0b
......@@ -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>
......
doc/src/sgml/user.sgml
View file @ 654f8f0b
<!--
$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;
-->
......
doc/src/sgml/xoper.sgml
View file @ 654f8f0b
......@@ -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
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment