----- Forwarded message from postgresql-general mailing list ----- Subject: Re: [GENERAL] psql -l
On Wednesday 18 July 2001 11:57, Tom Lane wrote: > will trillich <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> : 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/ ...
