psql -l: 'No database specified'
----- Forwarded message from postgresql-general mailing list -----
Subject: Re: [GENERAL] psql -l
On Wednesday 18 July 2001 11:57, Tom Lane wrote:
> will trillich <will@serensoft.com> writes:
> > with 7.0.3 (and 6.5.3) we could
> > $ psql -l
> > and get a list of databases. now, we have to
> > supply SOME database name regardless of whether
> > we need to connect or not:
> > $ 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
----- End forwarded message -----
what's the easy solution? can't we have "psql -l" work again
without needing a database name?
--
DEBIAN NEWBIE TIP #52 from Will Trillich <will@serensoft.com>
:
Would you like to GET APACHE TO HIDE CERTAIN FILES? It's
as easy as adding this to your /etc/apache/httpd.conf:
PerlModule Apache::Constants
<FilesMatch "\.hide$">
SetHandler perl-script
PerlInitHandler Apache::Constants::NOT_FOUND
</FilesMatch>
Your scripts, behind the scenes, still have free access to
everything; but web browsers will be told they don't exist!
Also see http://newbieDoc.sourceForge.net/ ...
Reply to: