Re: psql -l - Mailing list pgsql-general

On Wednesday 18 July 2001 11:57, Tom Lane wrote:
> will trillich <will@serensoft.com> writes:
> > $ psql -V
> > No database specified

> This seems awfully fishy, since (a) there is no such error message
> anywhere in 7.1, and (b) I don't get that behavior out of 7.1:

> Perhaps you are invoking psql through some kind of wrapper script that
> is doing the wrong thing?

Debian, perhaps?  From the Debian patchfile: (
http://non-us.debian.org/debian-non-US/pool/non-US/main/p/postgresql/postgresql_7.1.2-1.diff.gz
)
+Debian-specific features
+========================
+
+There are certain differences between the Debian version of PostgreSQL
+and the upstream version.  There are two reasons for this.  First,
+because Debian policy requires certain things to be done in a manner
+different from that used by the upstream developers, and second, because
+I perceive a difference between a piece of software that is put onto
+a machine by an ordinary user and one that is installed, as part of a
+distribution, by the system administrator.
+
+1. Environment variables: Debian forbids packages to depend on users'
+   setting environment variables.  For this reason, certain front-end
+   programs, especially psql, are run through a wrapper that sets up
+   the environment.
+
+2. Default database: the upstream version defaults to a database whose
+   name is the same as the name of the PostgreSQL user who is trying to
+    access it.  I do not think this is appropriate to a distribution, so
+    in Debian, the database must be specified on the command line or in
+    the environment variable PGDATABASE.
+
+3. Initialising the postmaster: the upstream version uses a program called
+   pg_ctl, that was introduced at release 7.0, to start up and stop the
+   postmaster.  I do not feel that this sits very comfortably with
+   Debian's way of starting backend processes, so I have continued to use
+   the procedure I developed for previous versions, whereby
+   /etc/init.d/postgresql calls postgresql-startup or start-stop-daemon.
+   I will be borrowing nice features from pg_ctl to incorporate in the
+   init.d script.
+
+4. Initial environment: Debian stores its setup files in /etc/postgresql.
+   These files are postmaster.conf, pg_hba.conf and postgresql.env, and any
+   files referenced by pg_hba.conf.  They are self-documented, so you are
+   advised to leave the coments alone if you edit them.  Where necessary,
+   there are symbolic links to the locations where the upstream code
+   expects to find them.
+
+5. Location of socket: in previous versions the socket file was located
+   in /tmp/.  It has now been moved to /var/run/postgresql/ so as to avoid
+    problems with packages such as tmpreaper and to be more consistent
+    with Debian policy.  This location can be altered by setting
+    UNIX_SOCKET_DIRECTORY in postgresql.conf.
+
+6. Unix socket authentication is provided (authentication type "peer").
+   This works just like ident, but for Unix sockets; this provides a more
+    secure method of authentication than ident, and does not require
+    administrators to run identd on their servers.  This authentication
+    method has been submitted to the upstream developers, but is not
+    currently part of the upstream release.
+

This excerpt from the file README.Debian.

The error message itself is being issued by the Debian 'pg_wrapper' program
(see the pg_wrapper source embedded in the patchfile starting at line 5434 --
the error message itself is at line 5646 in the patchfile).

I can sympathize with Oliver here -- distribution policy can be a pain to
deal with, although Red Hat's policy isn't apparently as strict as Debian's.
I also sympatchize and agree with Oliver's statement about differences
between packages that are installed by a user in /usr/local and packages
installed by the system administrator as part of an operating system.

We're not, eh, 'distribution-friendly' in reality -- although Peter's work on
the build system really helped the RPM side of things. The 'traditional
PostgreSQL installation' is more 'user-install'-centric -- which is OK, as
long as everybody knows what the packagers are doing... :-)
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11