Thread: New man pages

I've posted a tarball of new man pages at
 ftp://postgresql.org/pub/doc/man.tar.gz

I *think* these are ready for prime time, or close to it. They are
generated completely automatically from the sgml sources, using some
patched perl utilities. I'll try to post the complete set of docs
tools on the ftp site sometime soon.

Note that there are a few more man pages than were available in the
original versions, and that *all* information in the original man
pages appears in the new ones (or somewhere in the other docs).

I haven't yet updated the cvs tree to contain these new man pages.
Please look through the tarball and report any problems you see, if
you have any interest in the man page issue. Also, please report if
they look OK, so I know *someone* looked at them ;)
                  - Thomas

-- 
Thomas Lockhart                lockhart@alumni.caltech.edu
South Pasadena, California

> I've posted a tarball of new man pages at
> 
>   ftp://postgresql.org/pub/doc/man.tar.gz
> 
> I *think* these are ready for prime time, or close to it. They are
> generated completely automatically from the sgml sources, using some
> patched perl utilities. I'll try to post the complete set of docs
> tools on the ftp site sometime soon.
> 
> Note that there are a few more man pages than were available in the
> original versions, and that *all* information in the original man
> pages appears in the new ones (or somewhere in the other docs).
> 
> I haven't yet updated the cvs tree to contain these new man pages.
> Please look through the tarball and report any problems you see, if
> you have any interest in the man page issue. Also, please report if
> they look OK, so I know *someone* looked at them ;)

I looked at the new pages, and they looked very good, much better than I
thought they would.  The only problem was the display of the command
syntax was wrapped rather than being one operator per line:
      select [distinct [on attr_name]]          expression1 [as attr_name-1]          {, expression-1 [as attr_name-i]}
        [into [temp] [table] classname]          [from from-list]          [where where-clause]          [group by
attr_name1{, attr_name-i....}]          [having having-clause]
 

became:
      select [distinct [on attr_name]]  expression1 [as attr_name-1]          {, expression-1 [as attr_name-i]} [into
[temp][table] classname]          [from from-list] [where where-clause] [group by attr_name1    {, attr_name-i....}]
[havinghaving-clause]
 

Which is almost unreadable.

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 

> I looked at the new pages, and they looked very good, much better than I
> thought they would.

:)

>  The only problem was the display of the command
> syntax was wrapped rather than being one operator per line:
> Which is almost unreadable.

Fixed it.
                    - Thomas

-- 
Thomas Lockhart                lockhart@alumni.caltech.edu
South Pasadena, California

> > I looked at the new pages, and they looked very good, much better than I
> > thought they would.
> 
> :)

Yes, I was prepared to really lose some of the nice formatting we had,
but we really didn't lose anything.

> 
> >  The only problem was the display of the command
> > syntax was wrapped rather than being one operator per line:
> > Which is almost unreadable.
> 
> Fixed it.

Thanks.

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 

I mentioned this earlier in the context of pg_dump, which fails
trying to create the table "pgdump_oid".

After a bit, a memory jog reminded me that I've seen this
before, with the table "foo", which I once used for testing.

After a fair number of "create/drop" cycles, making then
dropping tables for testing, pgsql now refuses to let me
"create table foo...", giving the same simple error message
"can't create foo" as pg_dump's getting on pgdump_oid.

I can't "drop table foo", getting an error message telling
me the class doesn't exist, so that's not the problem.

I CAN create/drop other tables, i.e. "create table bar..."
followed by "drop table bar" works fine.

So it doesn't appear to be a general permissions problem,
i.e. it's not as though the system thinks I don't have
create table rights.

It would seem as some system table is being corrupted???

Does this sound at all familiar?

Unfortunately, I don't know how to reproduce this other
than create/drop tables until eventually it fails.  As
I mentioned in my first note, pg_dump has been running
nightly on this database for weeks, at least, with no
errors reported.  Suddenly - poof! can't create pgdump_oid.



- Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert
Serviceand other goodies at http://donb.photo.net.
 

Don Baccus wrote:
> I can't "drop table foo", getting an error message telling
> me the class doesn't exist, so that's not the problem.
> It would seem as some system table is being corrupted???

Check pg_tables and pg_class -- select * from pg_tables; will give you a
list of tables from the system catalog, and select * from ps_class; will
do the same for classes -- if the psuedo-dropped table shows in either
of these tables, delete it, and see if that helps.  If this indeed is a
system table corruption..... eeewwww....

Lamar Owen
WGCR Internet Radio

At 02:14 PM 8/6/99 -0400, Lamar Owen wrote:
>Don Baccus wrote:
> 
>> I can't "drop table foo", getting an error message telling
>> me the class doesn't exist, so that's not the problem.
> 
>> It would seem as some system table is being corrupted???
>
>Check pg_tables and pg_class -- select * from pg_tables; will give you a
>list of tables from the system catalog, and select * from ps_class; will
>do the same for classes -- if the psuedo-dropped table shows in either
>of these tables, delete it, and see if that helps.  If this indeed is a
>system table corruption..... eeewwww....

Neither "pgdump_oid" or "foo" (my other example from my
follow-up message) appear to exist in pg_class or pg_tables.

Thanks for the suggestion, though :(



- Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert
Serviceand other goodies at http://donb.photo.net.
 

At 11:23 AM 8/6/99 -0700, Don Baccus wrote:

>Neither "pgdump_oid" or "foo" (my other example from my
>follow-up message) appear to exist in pg_class or pg_tables.
>
>Thanks for the suggestion, though :(

Things are getting more and more odd...

I've done some more testing and things are now in a state
where I can create a table, drop the table (and get the
message "DROP" back), yet the relation still exists.

In fact, I can do a "select count(*) from ..." on it and
get zero rows back.

Argh!

Of course, now if I try to create a table with that name,
I'm told the relation already exists.

Different than the situation with pgdump_oid and foo,
where I'm just told that the create failed.

Obviously, some table contents somewhere must be messed
up.  Any ideas?



- Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert
Serviceand other goodies at http://donb.photo.net.
 

On Fri, Aug 06, 1999 at 11:54:31AM -0700, Don Baccus wrote:
> At 11:23 AM 8/6/99 -0700, Don Baccus wrote:
> 
> >Neither "pgdump_oid" or "foo" (my other example from my
> >follow-up message) appear to exist in pg_class or pg_tables.
> >
> >Thanks for the suggestion, though :(
> 
> Things are getting more and more odd...
> 
> I've done some more testing and things are now in a state
> where I can create a table, drop the table (and get the
> message "DROP" back), yet the relation still exists.
> 
> In fact, I can do a "select count(*) from ..." on it and
> get zero rows back.
> 
> Argh!
> 
> Of course, now if I try to create a table with that name,
> I'm told the relation already exists.
> 
> Different than the situation with pgdump_oid and foo,
> where I'm just told that the create failed.
> 
> Obviously, some table contents somewhere must be messed
> up.  Any ideas?
> 

Check to see if there are files in the pgsql/data/base/'yourdbname'
directory called 'pgdump_oid' and 'foo'. Some situations lead to a table
being almost completely deleted, but leaving the file behind. Doesn't
explain the 'table still there' phenomena, but might let you recreate a
'dropped' table.

Ross
P.S. once common problem is dropping a table doesn't always get all the
objects created by 'convenience' types. For example, not not sure the 
sequence created for a serial type gets dropped with its table. In fact,
I'm pretty sure it doesn't (and, for now, shouldn't)

-- 
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> 
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St.,  Houston, TX 77005

Don Baccus wrote:
> Obviously, some table contents somewhere must be messed
> up.  Any ideas?

Ooooo....

If this were happening to me, I'd probably stop postmaster, rename the
PGDATA tree to something else, initdb, start postmaster, restore from
the last good dump, stop postmaster, copy back the user database dirs
under PGDATA, restart postmaster, VACUUM all tables -- on the production
machine, if that is where the problems are. Then, I'd pull that PGDATA
binary backup over to a development workstation, start up a postmaster
pointing to it, and do a post-mortem, checking all system tables for
their contents, running vacuum, et al (all the while keeping a good copy
of the old PGDATA tree -- just in case something blows up).

Obviously, some system catalog somewhere is getting farkled -- Don, I'm
assuming that you are vacuuming often.

HTHaL

Lamar

At 03:53 PM 8/6/99 -0400, Lamar Owen wrote:
>Don Baccus wrote:
>> Obviously, some table contents somewhere must be messed
>> up.  Any ideas?
>
>Ooooo....
>
>If this were happening to me, I'd probably stop postmaster, rename the
>PGDATA tree to something else, initdb, start postmaster, restore from
>the last good dump, stop postmaster, copy back the user database dirs
>under PGDATA, restart postmaster, VACUUM all tables -- on the production
>machine, if that is where the problems are. Then, I'd pull that PGDATA
>binary backup over to a development workstation, start up a postmaster
>pointing to it, and do a post-mortem, checking all system tables for
>their contents, running vacuum, et al (all the while keeping a good copy
>of the old PGDATA tree -- just in case something blows up).

I decided awhile back to punt and rebuild.

>Obviously, some system catalog somewhere is getting farkled -- Don, I'm
>assuming that you are vacuuming often.

Nightly, after dumping.



- Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert
Serviceand other goodies at http://donb.photo.net.
 

At 02:46 PM 8/6/99 -0500, Ross J. Reedstrom wrote:

>Check to see if there are files in the pgsql/data/base/'yourdbname'
>directory called 'pgdump_oid' and 'foo'. Some situations lead to a table
>being almost completely deleted, but leaving the file behind. Doesn't
>explain the 'table still there' phenomena, but might let you recreate a
>'dropped' table.

Thanks, I thought of this one myself, and deleted "foo".  This is
when it got into the mode of allowing "create table foo..." and
an apparently successful "drop table foo", but with "foo" left
behind in pg_class (I think that's right) and "select count(*)
from foo" returning 0 rows (i.e. the relation really seems to
exist!)

>
>Ross
>P.S. once common problem is dropping a table doesn't always get all the
>objects created by 'convenience' types. For example, not not sure the 
>sequence created for a serial type gets dropped with its table. In fact,
>I'm pretty sure it doesn't (and, for now, shouldn't)

Yes, this isn't my problem, though.



- Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert
Serviceand other goodies at http://donb.photo.net.
 

Hi Thomas,

I'm looking at man pages, and I find it very good. Now we have only one
documentation's version. Nice job.
There's only a little thing that I would like to recall your attention;
I see whenever the name Postgres instead of
PostgreSQL. Is there a reason to continue to call it Postgres in the
docs ?

-------------------------------------------------------------------------

UPDATE(l)                                               UPDATE(l)

NAME      UPDATE - Replaces values of columns in a table

SYNOPSIS      UPDATE  table  SET  R">colle> = expression [, ...]  [ FROM
^^^^^^^     fromlist ] [ WHERE condition ]
 
  INPUTS      table  The name of an existing table.
      column The name of a column in table.
      expression             A valid expression or value to assign to column.
      fromlist             A Postgres non-standard extension to allow  columns                 ^^^^^^^             from
othertables to appear in the WHERE condition.
 

José


Thomas Lockhart ha scritto:

> I've posted a tarball of new man pages at
>
>   ftp://postgresql.org/pub/doc/man.tar.gz
>
> I *think* these are ready for prime time, or close to it. They are
> generated completely automatically from the sgml sources, using some
> patched perl utilities. I'll try to post the complete set of docs
> tools on the ftp site sometime soon.
>
> Note that there are a few more man pages than were available in the
> original versions, and that *all* information in the original man
> pages appears in the new ones (or somewhere in the other docs).
>
> I haven't yet updated the cvs tree to contain these new man pages.
> Please look through the tarball and report any problems you see, if
> you have any interest in the man page issue. Also, please report if
> they look OK, so I know *someone* looked at them ;)
>
>                    - Thomas
>
> --
> Thomas Lockhart                         lockhart@alumni.caltech.edu
> South Pasadena, California

> There's only a little thing that I would like to recall your attention;
> I see whenever the name Postgres instead of
> PostgreSQL. Is there a reason to continue to call it Postgres in the
> docs ?

I have chosen to use "Postgres" within the docs, as a shorter (and
pronouncable ;) form of our product. "PostgreSQL" appears in all
titles and introductory material. I have considered the "SQL" part of
the "PostgreSQL" as sort of a version or branch, like "OpenIngres" or
"Windows 2000", and a bit cumbersome in the body of the docs.

But that was a choice which can always be reconsidered, we're just a
"sed" away from a different name...
                     - Thomas

-- 
Thomas Lockhart                lockhart@alumni.caltech.edu
South Pasadena, California

> > There's only a little thing that I would like to recall your attention;
> > I see whenever the name Postgres instead of
> > PostgreSQL. Is there a reason to continue to call it Postgres in the
> > docs ?
> 
> I have chosen to use "Postgres" within the docs, as a shorter (and
> pronouncable ;) form of our product. "PostgreSQL" appears in all
> titles and introductory material. I have considered the "SQL" part of
> the "PostgreSQL" as sort of a version or branch, like "OpenIngres" or
> "Windows 2000", and a bit cumbersome in the body of the docs.
> 
> But that was a choice which can always be reconsidered, we're just a
> "sed" away from a different name...

I vote for PostgreSQL.

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 

On Mon, 9 Aug 1999, Bruce Momjian wrote:

> > > There's only a little thing that I would like to recall your attention;
> > > I see whenever the name Postgres instead of
> > > PostgreSQL. Is there a reason to continue to call it Postgres in the
> > > docs ?
> > 
> > I have chosen to use "Postgres" within the docs, as a shorter (and
> > pronouncable ;) form of our product. "PostgreSQL" appears in all
> > titles and introductory material. I have considered the "SQL" part of
> > the "PostgreSQL" as sort of a version or branch, like "OpenIngres" or
> > "Windows 2000", and a bit cumbersome in the body of the docs.
> > 
> > But that was a choice which can always be reconsidered, we're just a
> > "sed" away from a different name...
> 
> I vote for PostgreSQL.

I'm just an end user who loves the product...with an opinion.  ;-)

Although I never used postgres (i.e., prior to the suffix being appended)
I always use `postgres' in conversation both as it is easily pronounced
and as there is a rather noteable history/lineage.  When communicating
with other postgres fans I say pee-gee...

When I refer specfically to the newer incarnation I say Postgres SQL
(post-gress see-qwell) rather than postgreS-Q-L...

I don't really mind if the man pages get edited as if I ever choose to
read them to my 4 year old son I will swap in the generic name, on the
fly.  But we are not up to that point yet - my son is still learning
about grep.  ;-)

I fully appreciate what the name is designed to convey but it does not
roll off the tongue...so I kinda like Thomas' decision to stick with
the more generic term - and the more poetic.

Cheers,
Tom

------- North Richmond Community Mental Health Center -------

Thomas Good                                   MIS Coordinator
Vital Signs:                  tomg@ { admin | q8 } .nrnet.org                                         Phone:
718-354-5528                                          Fax:   718-354-5056                               
 
/* Member: Computer Professionals For Social Responsibility */ 

Thomas Lockhart wrote:
> I have chosen to use "Postgres" within the docs, as a shorter (and
> pronouncable ;) form of our product. "PostgreSQL" appears in all

How hard is it to say "Postgresquel", really?  Don't tell me you've been
saying "Postgres cue ell".....;-)

Lamar Owen
WGCR Internet Radio

On Mon, 9 Aug 1999, Lamar Owen wrote:

> Thomas Lockhart wrote:
> > I have chosen to use "Postgres" within the docs, as a shorter (and
> > pronouncable ;) form of our product. "PostgreSQL" appears in all
> 
> How hard is it to say "Postgresquel", really?  Don't tell me you've been
> saying "Postgres cue ell".....;-)

I have! I don't see that there is really any difference between saying
"postgresequel" and "postgres-cue-ell". The syllables are just switched.
(kind of) However, perhaps the inventors of this term could offer their
insight into their intended pronounciation.

-- 
Peter Eisentraut
PathWay Computing, Inc.

The only thing I hate about PostgreSQL is that it's hard to type with all
that mixed case.  I confess that I've always pronounced it "postgres"
anyway, so there!

The point of a name is to be distinctive and somewhat descriptive.
Postgres suffices to set the product off from other database systems.
There's no real need for the SQL to be in the name.  Even Microsoft, in
their eternal marketing battle, doesn't make a point of writing AccesSQL.

My two bits, and your mileage may vary.

On Mon, 9 Aug 1999, Peter Eisentraut wrote:

> On Mon, 9 Aug 1999, Lamar Owen wrote:
> 
> > Thomas Lockhart wrote:
> > > I have chosen to use "Postgres" within the docs, as a shorter (and
> > > pronouncable ;) form of our product. "PostgreSQL" appears in all
> > 
> > How hard is it to say "Postgresquel", really?  Don't tell me you've been
> > saying "Postgres cue ell".....;-)
> 
> I have! I don't see that there is really any difference between saying
> "postgresequel" and "postgres-cue-ell". The syllables are just switched.
> (kind of) However, perhaps the inventors of this term could offer their
> insight into their intended pronounciation.
> 
> -- 
> Peter Eisentraut
> PathWay Computing, Inc.
> 
> 
> 

On Mon, Aug 09, 1999 at 02:51:02PM -0500, J. Michael Roberts wrote:
> The only thing I hate about PostgreSQL is that it's hard to type with all
> that mixed case.  I confess that I've always pronounced it "postgres"
> anyway, so there!
> 
> The point of a name is to be distinctive and somewhat descriptive.
> Postgres suffices to set the product off from other database systems.
> There's no real need for the SQL to be in the name.  Even Microsoft, in
> their eternal marketing battle, doesn't make a point of writing AccesSQL.
> 

Well, that might be because MS-Access... isn't! Their SQL server product,
however is called,...

SQL Server!

Anyone else get cheesed off how MS seems to always try to co-opt generic
words and turn them into ProductNames(tm)? Word? Access? SQL? In my own
little rebellion, I make a point of prefixing MS- whenever I speak or
write about their products.


Ross
-- 
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> 
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St.,  Houston, TX 77005

Peter Eisentraut wrote:
> 
> On Mon, 9 Aug 1999, Lamar Owen wrote:
> > How hard is it to say "Postgresquel", really?  Don't tell me you've been
> > saying "Postgres cue ell".....;-)
> 
> I have! I don't see that there is really any difference between saying
> "postgresequel" and "postgres-cue-ell". The syllables are just switched.
> (kind of) However, perhaps the inventors of this term could offer their
> insight into their intended pronounciation.

Not post-gre'-se-quel -- post-gres'-quel. One less syllable.  At least,
that's how I've been saying it.  But, then again, when referring to
MySQL I don't say my-s-q-l; I say my'-squel.

Oh well...

Lamar

> > > I have chosen to use "Postgres" within the docs, as a shorter (and
> > > pronouncable ;) form of our product. "PostgreSQL" appears in all
> > How hard is it to say "Postgresquel", really?  Don't tell me you've been
> > saying "Postgres cue ell".....;-)

I'll bet that even the coiners of the term have some differences in
their pronunciation. For the record, I use "Postgres" usually, and
"Postgres-cue-ell" when forced...
                   - Thomas

Since we cap the "S", however you pronounce "SQL" should probably be
how you do the end of "PostgreSQL". Lamar, are you a "ess-quel"
person? That may be a regional dialect. Don't even get me started on
that: it took me years to get over my strong inclination to use
"hacker" to refer to a bad, clueless programmer...

-- 
Thomas Lockhart                lockhart@alumni.caltech.edu
South Pasadena, California

Thomas Lockhart wrote:
> 
> I'll bet that even the coiners of the term have some differences in
> their pronunciation. For the record, I use "Postgres" usually, and
> "Postgres-cue-ell" when forced...

> Since we cap the "S", however you pronounce "SQL" should probably be
> how you do the end of "PostgreSQL". Lamar, are you a "ess-quel"
> person? That may be a regional dialect.

Only in postgressive context (ouch...)

I have been known to say 'squel' (as opposed to ess-quel....).  If I
could just inflect my Southern Drawl in text.... And I have said ess cue
ell (not very often...)... Oh well.  Minor points.  I think it goes back
to my Z80 days, where I'd pronounce the machine code -- it sounds real
strange to say "sidbateotwo" to mean CD B8 02 (CALL x'02B8' in Z80
assembler), but I have actually done that. Just a little game that a
friend and I would play.

Incidentally, radically changing the subject, I have done some tests on
the RPM-packaged perl client, with great success.  I am also
experimenting with my new (3lo) RPM's, which are the first try to
package the regression tests.  Now to see if they run ;-/  As soon as
the RedHat 5.2 machine (a creaky 486-100 w/16MB) finishes a good build,
I'll post.  Although, I am hitting snags -- the regression tests have
some strange requirements -- ie, the resulting regress.so in the package
is built to require /usr/local/bin/perl, and /usr/local/bin/python..... 
Oh well; I'll slog through it.

Now to learn enough python to be dangerous...

Lamar

> I have done some tests on
> the RPM-packaged perl client, with great success.

That's building the client into the distro-specific directories for
perl? Great...

> I am also
> experimenting with my new (3lo) RPM's, which are the first try to
> package the regression tests.  Now to see if they run ;-/  As soon as
> the RedHat 5.2 machine (a creaky 486-100 w/16MB) finishes a good build,
> I'll post.  Although, I am hitting snags -- the regression tests have
> some strange requirements -- ie, the resulting regress.so in the package
> is built to require /usr/local/bin/perl, and /usr/local/bin/python.....
> Oh well; I'll slog through it.

Keep on patching. It's pretty convenient for stuff like this...

> Now to learn enough python to be dangerous...

Dangerous doesn't take very long. I haven't progressed past that yet,
at least for python (others may suggest other topics too ;)

I was just rebuilding the plain RPMs to include the .a forms of the
libraries, and noticed problems with:

1) naming the programming language shared libraries (not libpltcl.so
but pltcl.so, etc)

2) finding bin/pgaccess/README.pga (it is obsolete)
2a) bin/pgaccess/README should be included in the pgaccess docs target

Here is the spec file for you to compare to previous versions; perhaps
you can forward your spec file so I don't have to download an entire
-src.rpm to start scoping it out?

                         - Thomas

--
Thomas Lockhart                lockhart@alumni.caltech.edu
South Pasadena, CaliforniaSummary: The Postgres SQL database package.
Name: postgresql
Version: 6.5.1
Release: 2
Copyright: BSD
Group: Applications/Databases
Source0: ftp://ftp.postgresql.org/pub/postgresql-%{version}.tar.gz
Source1: ftp://www.flex.ro/pub/pgaccess/pgaccess-0.96.tar.gz
Source2: http://www.retep.org.uk/postgres/jdbc6.5-1.1.jar
Source3: postgresql.init
Source4: pgsql-Database-HOWTO-html.tar.gz
Buildroot: /var/tmp/pgsql-root
Prefix: /usr
Prereq: /sbin/chkconfig /sbin/ldconfig /usr/sbin/useradd
Vendor: The PostgreSQL Global Development Group
Packager: Thomas Lockhart <lockhart@alumni.caltech.edu>
Url: http://www.postgresql.org/
ExcludeArch: alpha armv4l
Conflicts: postgresql-clients

%description
PostgreSQL is an advanced Object-Relational database management system
(DBMS) that supports almost all SQL constructs (including transactions,
subselects and user-defined types and functions).
postgresql includes the client programs and client libraries
that you'll need to access a PostgreSQL database management system
server.  This package contains the client libraries for C, and C++,
as well as command-line utilities for managing PostgreSQL databases on a
remote server. If you just want to connect to an existing remote
PostgreSQL server, this package is all you need.

You should install postgresql if you're installing postgresql-server.

%package server
Summary: The programs needed for a PostgreSQL server.
Group: Applications/Databases
Requires: postgresql = %{version}

%description server
postgresql-server includes the programs needed to create and run a PostgreSQL
server, which will in turn allow you to create and maintain PostgreSQL
databases.  PostgreSQL is an advanced Object-Relational database
management system (DBMS) that supports almost all SQL constructs
(including transactions, subselects and user-defined types and
functions).

You should install postgresql if you want to create and maintain your
own PostgreSQL databases and/or your own PostgreSQL server.

%package devel
Summary: PostgreSQL development header files and libraries.
Group: Development/Libraries

%description devel
This package contains the header files and libraries needed to
compile C or C++ applications which will directly interact with
a PostgreSQL server. It include the ecpg Embedded C Postgres
preprocessor.

Install this package if you want to develop applications which will
interact with a PostgreSQL server.

%package tcl
Summary: The tcl-based client programs needed for accessing a PostgreSQL server.
Group: Applications/Databases
Requires: tcl >= 8.0, tk >= 8.0

%description tcl
postgresql-tcl includes the tcl-based client programs and client libraries
that you'll need to access a PostgreSQL database management system
server.  This package contains the tcl client libraries,
as well as pgaccess, a wish-based utility for manipulating PostgreSQL databases.

%package odbc
Summary: The ODBC driver needed for accessing a PostgreSQL server.
Group: Applications/Databases

%description odbc
Postgresql-odbc includes the odbc driver and sample configuration files
that you'll need to access a PostgreSQL database management system
server.

%package perl
Summary: The perl-based client programs needed for accessing a PostgreSQL server.
Group: Applications/Databases
Requires: perl >= 5.004-4

%description perl
postgresql-perl includes the perl-based client programs and client libraries
that you'll need to access a PostgreSQL database management system
server.

%package python
Summary: The python-based client programs needed for accessing a PostgreSQL server.
Group: Applications/Databases
Requires: python >= 1.5

%description python
postgresql-python includes the python-based client programs and client libraries
that you'll need to access a PostgreSQL database management system
server.

%package jdbc
Summary: The java-based client programs needed for accessing a PostgreSQL server.
Group: Applications/Databases

%description jdbc
postgresql-jdbc includes the jar file that you'll need to access a PostgreSQL
database management system server.

%prep
%setup -q
cd src/bin
gzip -dc $RPM_SOURCE_DIR/pgaccess-0.96.tar.gz | tar -xvvf -

%build
pushd src
CFLAGS="$RPM_OPT_FLAGS" ./configure --prefix=/usr \
    --enable-hba --enable-locale \
    --with-perl \
    --with-tcl --with-tk --with-x \
    --with-odbc --with-java \
    --with-python
make all
pushd interfaces/python
cp /usr/lib/python1.5/config/Makefile.pre.in .
echo *shared* > Setup
echo _pg pgmodule.c -I../../include -I../libpq -L../libpq -lpq -lcrypt >> Setup
make -f Makefile.pre.in boot
make
popd
popd

make all PGDOCS=unpacked -C doc

%install
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT/usr/{include/pgsql,lib,bin}
mkdir -p $RPM_BUILD_ROOT/usr/lib/perl5/site_perl/%{buildarch}-linux/auto/Pg
make POSTGRESDIR=$RPM_BUILD_ROOT/usr PREFIX=$RPM_BUILD_ROOT/usr -C src install
make POSTGRESDIR=$RPM_BUILD_ROOT/usr PREFIX=$RPM_BUILD_ROOT/usr -C src/man install
make POSTGRESDIR=$RPM_BUILD_ROOT/usr PREFIX=$RPM_BUILD_ROOT/usr -C src/interfaces/perl5 install
# Get rid of the packing list generated by the perl Makefile, and build my own...
find $RPM_BUILD_ROOT/usr/lib/perl5 -name .packlist -exec rm -f {} \;
find $RPM_BUILD_ROOT/usr/lib/perl5 -type f -print | \
    sed -e "s|$RPM_BUILD_ROOT/|/|g" > perlfiles.list
find $RPM_BUILD_ROOT/usr/lib/perl5 -type d -name Pg -print | \
    sed -e "s|$RPM_BUILD_ROOT/|%dir /|g" >> perlfiles.list
make -C doc

# Move all includes beneath /usr/include/pgsql.
pushd $RPM_BUILD_ROOT/usr/include
rm -rf include
for f in *.h access commands executor lib libpq libpq++ port utils ; do
    mv $f pgsql
done
popd

# Move all templates/examples beneath /usr/lib/pgsql
pushd $RPM_BUILD_ROOT/usr/lib
mkdir -p pgsql
mv *source *sample pgsql
popd

# TCL/TK
install -m 0755 src/bin/pgaccess/pgaccess.tcl $RPM_BUILD_ROOT/usr/bin/pgaccess

# Perl
# No need to do anything right now. But later, we will try building everything
# on the target machine to use the architecture-specific installation features
# in the perl installation.
#pushd src/interfaces/perl5
#mkdir -p $RPM_BUILD_ROOT/usr/lib/pgsql/perl5
#cp Pg.pm $RPM_BUILD_ROOT/usr/lib/pgsql/perl5
#pushd blib/arch/auto/Pg
#cp Pg.so Pg.bs $RPM_BUILD_ROOT/usr/lib/pgsql/perl5
#popd
#popd

# Python
pushd src/interfaces/python
# Makefile.pre.in doesn't yet support .py files anyway, so we stick to a manual installation
mkdir -p $RPM_BUILD_ROOT/usr/lib/python1.5/site-packages
install -m 644 _pgmodule.so *.py $RPM_BUILD_ROOT/usr/lib/python1.5/site-packages/
popd

# Java/JDBC
# We know that JDK1.2 is pre-beta at this time, so just install the JDK1.1-compatible driver.
# The user will have to set a CLASSPATH to find it here, but not sure where else to put it...
install -m 755 $RPM_SOURCE_DIR/jdbc6.5-1.1.jar $RPM_BUILD_ROOT/usr/lib/pgsql

chmod 644 $RPM_BUILD_ROOT/usr/man/*/*
install -d $RPM_BUILD_ROOT/etc/rc.d/init.d
install -m 755 $RPM_SOURCE_DIR/postgresql.init $RPM_BUILD_ROOT/etc/rc.d/init.d/postgresql
for I in 3 5; do
    install -d $RPM_BUILD_ROOT/etc/rc.d/rc$I.d
    pushd $RPM_BUILD_ROOT/etc/rc.d/rc$I.d
    ln -s ../init.d/postgresql S99postgresql
    popd
done

## Create sample database
## Disabled because an in-place upgrade using rpm only is probably not the right thing to do.
## Also, it is a PITA; should let the user decide how to coordinate dump and reload if necessary.
mkdir -p $RPM_BUILD_ROOT/var/lib/pgsql
#PATH=/usr/sbin:$PATH useradd -M -r -d /var/lib/pgsql -s /bin/bash \
#    -c "PostgreSQL Server" postgres || :
#chown -R postgres.postgres $RPM_BUILD_ROOT/var/lib/pgsql
#export PATH=$PATH:$RPM_BUILD_ROOT/usr/bin
#[ ! -f $RPM_BUILD_ROOT/usr/lib/libpq.so.1 ] && ln -sf libpq.so $RPM_BUILD_ROOT/usr/lib/libpq.so.1
#unset ENV || :
#su postgres -c "LD_LIBRARY_PATH=$RPM_BUILD_ROOT/usr/lib \
#  $RPM_BUILD_ROOT/usr/bin/initdb --pgdata=$RPM_BUILD_ROOT/var/lib/pgsql \
#        --pglib=$RPM_BUILD_ROOT/usr/lib/pgsql"
#[ -L $RPM_BUILD_ROOT/usr/lib/libpq.so.1 ] && rm -f $RPM_BUILD_ROOT/usr/lib/libpq.so.1
## this was a good one
#chmod 640 $RPM_BUILD_ROOT/var/lib/pgsql/pg_pwd

mkdir -p howto
tar xzf $RPM_SOURCE_DIR/pgsql-Database-HOWTO-html.tar.gz -C howto
mkdir -p pgaccess
cp src/bin/pgaccess/README pgaccess
cp src/bin/pgaccess/*.html pgaccess
cp src/bin/pgaccess/*.sql pgaccess

# Strip 'em all
strip $RPM_BUILD_ROOT/usr/bin/* || :

%pre server
useradd -M -o -r -d /var/lib/pgsql -s /bin/bash \
    -c "PostgreSQL Server" postgres >/dev/null 2>&1 || :

%post -p /sbin/ldconfig

%post -p /sbin/ldconfig server

%post perl
# We *should* use the architecture-specific area to hold our perl interface.
# For now, we will use the architecture-neutral areas, and prebuild everything.
#PerlTarget=`perl -MConfig -e 'print $Config{archlib}'`
#pushd /usr/lib/pgsql/perl5
#mv Pg.pm $PerlTarget/
#mv Pg.so Pg.bs $PerlTarget/auto/Pg/
#popd

%post -p /sbin/ldconfig odbc

%post -p /sbin/ldconfig tcl

%preun
if [ $1 = 0 ] ; then
    chkconfig --del postgresql
fi

%postun -p /sbin/ldconfig

%postun server
/sbin/ldconfig
if [ $1 = 0 ] ; then
    userdel postgres >/dev/null 2>&1 || :
fi

%postun -p /sbin/ldconfig odbc

%postun -p /sbin/ldconfig tcl

%clean
rm -rf $RPM_BUILD_ROOT
rm -f perlfiles.list
rm -rf howto

%files
%defattr(-,root,root)
%doc doc/FAQ doc/FAQ_Linux doc/README*
%doc COPYRIGHT README HISTORY doc/bug.template
%doc contrib doc/unpacked/*
%doc doc/*.ps.gz
%doc howto
%doc pgaccess
%attr(755,root,root) /usr/lib/*.a
%attr(755,root,root) /usr/lib/libpq.so*
%attr(755,root,root) /usr/lib/libecpg.so*
%attr(755,root,root) /usr/lib/libpq++.so*
/usr/man/manl/*
/usr/bin/createdb
/usr/bin/createuser
/usr/bin/destroydb
/usr/bin/destroyuser
/usr/bin/pg_dump
/usr/bin/pg_dumpall
/usr/bin/pg_id
/usr/bin/psql
/usr/man/man1/createdb.1
/usr/man/man1/createuser.1
/usr/man/man1/destroydb.1
/usr/man/man1/destroyuser.1
/usr/man/man1/pg_dump.1
/usr/man/man1/pg_dumpall.1
/usr/man/man1/psql.1
/usr/man/man1/vacuumdb.1


%files server
%defattr(-,root,root)
%config /etc/rc.d/*
%attr(755,root,root) /usr/lib/plpgsql.so*
%attr(755,root,root) /usr/lib/pltcl.so*
/usr/man/man5/*
/usr/bin/cleardbdir
/usr/bin/initdb
/usr/bin/initlocation
/usr/bin/pg_passwd
/usr/bin/pg_version
/usr/bin/postgres
/usr/bin/postmaster
/usr/man/man1/cleardbdir.1
/usr/man/man1/initdb.1
/usr/man/man1/initlocation.1
/usr/man/man1/ipcclean.1
/usr/man/man1/pg_passwd.1
#/usr/man/man1/pgadmin.1
/usr/man/man1/postgres.1
/usr/man/man1/postmaster.1
%attr(-,postgres,postgres) %dir /var/lib/pgsql

%files devel
%defattr(-,root,root)
/usr/lib/pgsql
/usr/include/pgsql
/usr/man/man3/*
/usr/bin/ecpg
/usr/man/man1/ecpg.1

%files tcl
%defattr(-,root,root)
%attr(755,root,root) /usr/lib/libpgtcl.so*
/usr/man/man1/pgaccess.1
#/usr/man/man1/pgtclsh.1
#/usr/man/man1/pgtksh.1
/usr/bin/pgaccess
/usr/bin/pgtclsh
/usr/bin/pgtksh

%files odbc
%defattr(-,root,root)
%attr(755,root,root) /usr/lib/libpsqlodbc.so*

%files -f perlfiles.list perl
%dir /usr/lib/perl5/site_perl/%{buildarch}-linux/auto

%files python
%defattr(-,root,root)
/usr/lib/python1.5/site-packages/_pgmodule.so
/usr/lib/python1.5/site-packages/*.py

%files jdbc
%defattr(-,root,root)
/usr/lib/pgsql/jdbc6.5-1.1.jar

%changelog
* Tue Jul 27 1999 Thomas Lockhart <lockhart@alumni.caltech.edu>
- version 6.5.1

* Sat Jun 19 1999 Thomas Lockhart <lockhart@alumni.caltech.edu>
- deprecate clients rpm, and define a server rpm for the backend
- version 6.5
- updated pgaccess to version 0.96
- build ODBC interface library
- split tcl and ODBC packages into separate binary rpms

* Sat Apr 17 1999 Jeff Johnson <jbj@redhat.com>
- exclude alpha for Red Hat 6.0.

* Sun Mar 21 1999 Cristian Gafton <gafton@redhat.com>
- auto rebuild in the new build environment (release 2)

* Wed Feb 03 1999 Cristian Gafton <gafton@redhat.com>
- version 6.4.2
- get rid of the -data package (shipping it was a BAD idea)

* Sat Oct 10 1998 Cristian Gafton <gafton@redhat.com>
- strip all binaries
- use defattr in all packages
- updated pgaccess to version 0.90
- /var/lib/pgsql/pg_pwd should not be 666

* Sun Jun 21 1998 Jeff Johnson <jbj@redhat.com>
- create /usr/lib/pgsql (like /usr/include/pgsql)
- resurrect libpq++.so*
- fix name problem in startup-script (problem #533)

* Fri Jun 19 1998 Jeff Johnson <jbj@redhat.com>
- configure had "--prefix=$RPM_BUILD_ROOT/usr"
- move all include files below /usr/include/pgsql.
- resurrect perl client file lists.

* Tue May 05 1998 Prospector System <bugs@redhat.com>
- translations modified for de, fr, tr

* Tue May 05 1998 Cristian Gafton <gafton@redhat.com>
- build on alpha

* Sat May 02 1998 Cristian Gafton <gafton@redhat.com>
- enhanced initscript

* Tue Apr 21 1998 Cristian Gafton <gafton@redhat.com>
- finally v6.3.2 is here !

* Wed Apr 15 1998 Cristian Gafton <gafton@redhat.com>
- added the include files in the devel package

* Wed Apr 01 1998 Cristian Gafton <gafton@redhat.com>
- finally managed to get a patch for 6.3.1 to make it install corectly. Boy,
  what a mess ! ;-(

* Tue Mar 03 1998 Cristian Gafton <gafton@redhat.com>
- upgraded tp 6.3 release

* Sat Feb 28 1998 Cristian Gafton <gafton@redhat.com>
- upgraded to the latest snapshot
- splitted yet one more subpackage: clients

* Tue Jan 20 1998 Cristian Gafton <gafton@redhat.com>
- the installed devel-library is no longer stripped (duh!)
- added the 7 patches found on the ftp.postgresql.org site
- corrected the -rh patch to patch configure.in rather than configure; we
  now use autoconf
- added a patch to fix the broken psort function
- build TCL and C++ libraries as well
- updated pgaccess to version 0.76

* Thu Oct 23 1997 Cristian Gafton <gafton@redhat.com>
- cleaned up the spec file for version 6.2.1
- splited devel subpackage
- added chkconfig support in %preun and %post
- added optional data package

* Mon Oct 13 1997 Elliot Lee <sopwith@cuc.edu> 6.2-3
- Fixed lots of bung-ups in the spec file, made it FSSTND compliant, etc.
- Removed jdbc package, jdk isn't stable yet as far as what goes where.
- Updated to v 6.2.1

* Thu Oct  9 1997 10:58:14 dan
- on pre-installation script now the `data' dir is renamed to
  `data.rpmorig' (no more wild deletions!).
- added `postgresql-jdbc' sub-package.
- postgresql.sh script: defined function `add_to_path()' and
  changed the location of postgresql.jar in the CLASSPATH.

* Sat Oct  4 1997 10:27:43 dan
- updated to version 6.2.
- added auto installation's scripts (pre, post, preun, postun)

Thomas Lockhart wrote:
> That's building the client into the distro-specific directories for
> perl? Great...

Actually, no -- it's doing exactly what your first run of it did -- and
it works. a simple connect-slect-fetchrows sequence did exactly as
expected -- and fancier constructs worked.  My take on that is to say
that, if it works, use it -- it is being put ina reasonable place with
your install, and perl is happy.  I've done some fairly extensive tests
of that interface, and have yet to crash it.

> > some strange requirements -- ie, the resulting regress.so in the package
> > is built to require /usr/local/bin/perl, and /usr/local/bin/python.....
> > Oh well; I'll slog through it.
> 
> Keep on patching. It's pretty convenient for stuff like this...

Well, I found that it wasn't the regression tests _per se_ that was
causing a failed requires for /usr/local/bin/[perl,python], but some
miscellaneous testing scripts in the test tree -- for reasons of
completness, I'm packaging the whole test tree -- not just the
regression tests, but the performance tests, benchmarks, et al.  On a
RedHat system, perl is always at /usr/bin/perl, and python is always at
/usr/bin/python, but it's easy enough to issue a which perl or which
python to make sure, and to make the RPM as portable as RPM's can get.

> I was just rebuilding the plain RPMs to include the .a forms of the
> libraries, and noticed problems with:
> 
> 1) naming the programming language shared libraries (not libpltcl.so
> but pltcl.so, etc)

Got those.

> 2) finding bin/pgaccess/README.pga (it is obsolete)
> 2a) bin/pgaccess/README should be included in the pgaccess docs target

That's one I haven't yet corrected... Although I have included 0.97b of
the pgaccess tcl script, as /usr/bin/pgaccess97, for testing.

> Here is the spec file for you to compare to previous versions; perhaps
> you can forward your spec file so I don't have to download an entire
> -src.rpm to start scoping it out?

http://www.ramifordistat.net/postgres/postgresql-6.5.1-2lo.spec is the
one I last released.  3lo is not ready for prime-time -- however, I've
uploaded it to postgresql-6.5.1-3lo.spec.beta in the same directory,
rather than take up list bandwidth.

Lamar

On Tue, 10 Aug 1999, Thomas Lockhart wrote:

> > > > I have chosen to use "Postgres" within the docs, as a shorter (and
> > > > pronouncable ;) form of our product. "PostgreSQL" appears in all
> > > How hard is it to say "Postgresquel", really?  Don't tell me you've been
> > > saying "Postgres cue ell".....;-)
> 
> I'll bet that even the coiners of the term have some differences in
> their pronunciation. For the record, I use "Postgres" usually, and
> "Postgres-cue-ell" when forced...
> 
>                     - Thomas
> 
> Since we cap the "S", however you pronounce "SQL" should probably be
> how you do the end of "PostgreSQL". Lamar, are you a "ess-quel"
> person? That may be a regional dialect. Don't even get me started on
> that: it took me years to get over my strong inclination to use
> "hacker" to refer to a bad, clueless programmer...

And how do you say Linux, Thomas?  I have a friend in Regina, Saskatchewan
(that's ra-Jine-ah, not ra-geen-ah) who says LINE-ex...I wince every time
I hear it.  In fact, sometimes, if I'm less than fully caffeinated it
doesn't even register that he's made a reference to Linn-Ucks...
(Usually I truncate it to Lin-icks or simply:  Slackware ;-)

------- North Richmond Community Mental Health Center -------

Thomas Good                                   MIS Coordinator
Vital Signs:                  tomg@ { admin | q8 } .nrnet.org                                         Phone:
718-354-5528                                          Fax:   718-354-5056                               
 
/* Member: Computer Professionals For Social Responsibility */ 

> And how do you say Linux, Thomas?  I have a friend in Regina, Saskatchewan
> (that's ra-Jine-ah, not ra-geen-ah) who says LINE-ex...I wince every time
> I hear it.  In fact, sometimes, if I'm less than fully caffeinated it
> doesn't even register that he's made a reference to Linn-Ucks...
> (Usually I truncate it to Lin-icks or simply:  Slackware ;-)

*rolf* Actually, that's a problem! When I first started with
linn-ucks, the person who got me going pronounced it line-ex. And
later, when I asked, she said that she intentionally mispronounced it
so she could trace the lineage of the person; that is, so she could
tell if they had learned about it from someone that she knew. Pretty
dastardly... ;)

But I try to pronounce it in Finnish rather than Texan nowadays...
                       - Thomas

-- 
Thomas Lockhart                lockhart@alumni.caltech.edu
South Pasadena, California

On Mon, 9 Aug 1999, Lamar Owen wrote:

> Thomas Lockhart wrote:
> > I have chosen to use "Postgres" within the docs, as a shorter (and
> > pronouncable ;) form of our product. "PostgreSQL" appears in all
> 
> How hard is it to say "Postgresquel", really?  Don't tell me you've been
> saying "Postgres cue ell".....;-)

Ummm, your second way is the correct pronounciation :)

Post-gres-Q-L :)

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 

On Mon, 9 Aug 1999, Bruce Momjian wrote:

> > > There's only a little thing that I would like to recall your attention;
> > > I see whenever the name Postgres instead of
> > > PostgreSQL. Is there a reason to continue to call it Postgres in the
> > > docs ?
> > 
> > I have chosen to use "Postgres" within the docs, as a shorter (and
> > pronouncable ;) form of our product. "PostgreSQL" appears in all
> > titles and introductory material. I have considered the "SQL" part of
> > the "PostgreSQL" as sort of a version or branch, like "OpenIngres" or
> > "Windows 2000", and a bit cumbersome in the body of the docs.
> > 
> > But that was a choice which can always be reconsidered, we're just a
> > "sed" away from a different name...
> 
> I vote for PostgreSQL.

I second it...whenever ppl mention "postgres", i think back to our
ancestor and figure they are referring to that :(


Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 

The Hermit Hacker wrote:
> > How hard is it to say "Postgresquel", really?  Don't tell me you've been
> > saying "Postgres cue ell".....;-)
> 
> Ummm, your second way is the correct pronounciation :)
> 
> Post-gres-Q-L :)

Correct or not, it doesn't quite flow off the tongue... Oh well.  There
are more important issues than pronunciation (such as rpm -Uvh for the
rpm's...), but a little levity never exacerberated any problems....
(laughter is the best medicine!).  Maybe we need you to record the
canonical pronunciation (I'll even encode to RealAudio -- and will
donate the RealServer bandwidth!), like Linus did for linux.
(lee-nooks...).

Cheers....

Lamar Owen
WGCR Internet Radio