psql -l

will trillich writes:

in the old days (7.0.3) i could list databases via

psql -l

but these days (7.1) i must

psql -l [-d] nameOfADatabaseFromPreordainedKnowledge

probably because of some fuxnored setting. but which?

Evidence please?

--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter

will trillich <will@serensoft.com> writes:

in the old days (7.0.3) i could list databases via
psql -l
but these days (7.1) i must
psql -l [-d] nameOfADatabaseFromPreordainedKnowledge
probably because of some fuxnored setting. but which?

Sounds like you've got pg_hba.conf set to disallow connections to
template1, which is what psql tries to connect to when executing
a plain "psql -l".

regards, tom lane

in the old days (7.0.3) i could list databases via

psql -l

but these days (7.1) i must

psql -l [-d] nameOfADatabaseFromPreordainedKnowledge

probably because of some fuxnored setting. but which?

psql -l works fine for me... 7.1.2. Does it return an error or just not
work?

Greg

will trillich <will@serensoft.com> writes:

in the old days (7.0.3) i could list databases via
psql -l
but these days (7.1) i must
psql -l [-d] nameOfADatabaseFromPreordainedKnowledge
probably because of some fuxnored setting. but which?

Sounds like you've got pg_hba.conf set to disallow connections to
template1, which is what psql tries to connect to when executing
a plain "psql -l".

Ewe, I never realized the problems with disabling template1
connections.

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

On Tue, Jul 17, 2001 at 09:26:02PM +0200, Peter Eisentraut wrote:

will trillich writes:

in the old days (7.0.3) i could list databases via

psql -l

but these days (7.1) i must

psql -l [-d] nameOfADatabaseFromPreordainedKnowledge

probably because of some fuxnored setting. but which?

Evidence please?

this was 7.0.3, as it'll tell you:

$ psql -V
psql (PostgreSQL) 7.0.3
contains readline, history, multibyte support
Portions Copyright (c) 1996-2000, PostgreSQL, Inc
Portions Copyright (c) 1996 Regents of the University of California
Read the file COPYRIGHT or use the command \copyright to see the
usage and distribution terms.

$ psql -l
List of databases
Database | Owner | Encoding
-----------+----------+----------
admin | rdt | LATIN1
agf | will | LATIN1
camp | rdt | LATIN1
ed | will | LATIN1
gunk | will | LATIN1
puz | will | LATIN1
secsed | will | LATIN1
template1 | postgres | LATIN1
testorama | will | LATIN1
tharp | rdt | LATIN1
tips | will | LATIN1
will | will | LATIN1
(12 rows)

but with v 7.1 i get

$ psql -V
No database specified
$ psql -l
No database specified
$ psql -V mydb
psql (PostgreSQL) 7.1
contains readline, history, multibyte support
Portions Copyright (c) 1996-2001, PostgreSQL Global Development Group
Portions Copyright (c) 1996 Regents of the University of California
Read the file COPYRIGHT or use the command \copyright to see the
usage and distribution terms.

--
I'd concentrate on "living in the now" because it is fun
and on building a better world because it is possible.
- Tod Steward

will@serensoft.com
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!

On Tue, Jul 17, 2001 at 04:34:29PM -0400, Tom Lane wrote:

will trillich <will@serensoft.com> writes:

in the old days (7.0.3) i could list databases via
psql -l
but these days (7.1) i must
psql -l [-d] nameOfADatabaseFromPreordainedKnowledge
probably because of some fuxnored setting. but which?

Sounds like you've got pg_hba.conf set to disallow connections to
template1, which is what psql tries to connect to when executing
a plain "psql -l".

here's the totality of pg_hba.conf (sans comments):

# grep -v '#' /etc/postgresql/pg_hba.conf | uniq

local all trust
host all 127.0.0.1 255.0.0.0 trust
host all 192.168.1.0 255.255.255.0 trust
host all 0.0.0.0 0.0.0.0 crypt

$ psql -V
No database specified

$ psql -V template0
psql (PostgreSQL) 7.1
contains readline, history, multibyte support
Portions Copyright (c) 1996-2001, PostgreSQL Global Development Group
Portions Copyright (c) 1996 Regents of the University of California
Read the file COPYRIGHT or use the command \copyright to see the
usage and distribution terms.

curiouser and curiouser.

--
I'd concentrate on "living in the now" because it is fun
and on building a better world because it is possible.
- Tod Steward

will@serensoft.com
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!

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:

$ ~postgres/version71/bin/psql -V
psql (PostgreSQL) 7.1.2
contains readline, history support
Portions Copyright (c) 1996-2001, PostgreSQL Global Development Group
Portions Copyright (c) 1996 Regents of the University of California
Read the file COPYRIGHT or use the command \copyright to see the
usage and distribution terms.
$

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

regards, tom lane

On Wed, Jul 18, 2001 at 11:57:35AM -0400, 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:

$ ~postgres/version71/bin/psql -V
psql (PostgreSQL) 7.1.2
contains readline, history support
Portions Copyright (c) 1996-2001, PostgreSQL Global Development Group
Portions Copyright (c) 1996 Regents of the University of California
Read the file COPYRIGHT or use the command \copyright to see the
usage and distribution terms.
$

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

i'm wondering now if this may be a debian packaging mishap...
or maybe i've got psql v7.0.3 trying to work with postmaster
7.1, but that doesn't seem likely...

at any rate -- maybe this session with 'strings' might help you
see identify what's goofing up here.

--
I'd concentrate on "living in the now" because it is fun
and on building a better world because it is possible.
- Tod Steward

will@serensoft.com
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!

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

On Wednesday 18 July 2001 15:30, Lamar Owen wrote:

Debian's. I also sympatchize and agree with Oliver's statement about

^^^^^^^^^^^
Freudian slip... ROTFL....
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

What is not appropriate is that we are getting error reports for
programs we didn't write!

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?

[ Much pontificating skipped.]

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

On Wednesday 18 July 2001 16:30, Bruce Momjian wrote:

What is not appropriate is that we are getting error reports for
programs we didn't write!

Which is why I believe that Red Hat's 'relabeling' is a Good Thing -- _they_
will get bug reports for 'Red Hat Database' -- then _they_ can contact the
hackers list after verifying that it isn't their 'modifications' causing the
problem.

I really try to make the RPM's patching minimal -- directory paths, a README,
migration helper scripts, and the initscript are the only 'enhancements' I
provide. And I try to field any reports I see on the list....

However, Oliver is a part of 'we' isn't he?

[ Much pontificating skipped.]

Interesting choice of words.... I wasn't intending to sound authoritarian....
or religious. Sorry if I did sound pontifical.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

On Wednesday 18 July 2001 16:30, Bruce Momjian wrote:

What is not appropriate is that we are getting error reports for
programs we didn't write!

Which is why I believe that Red Hat's 'relabeling' is a Good Thing -- _they_
will get bug reports for 'Red Hat Database' -- then _they_ can contact the
hackers list after verifying that it isn't their 'modifications' causing the
problem.

I really try to make the RPM's patching minimal -- directory paths, a README,
migration helper scripts, and the initscript are the only 'enhancements' I
provide. And I try to field any reports I see on the list....

However, Oliver is a part of 'we' isn't he?

The strange part is that we are running around trying to figure out if
it is a bug and no one knows that Debian has modified it.

The Red Hat stuff isn't a problem because you recoginize it as such.

[ Much pontificating skipped.]

Interesting choice of words.... I wasn't intending to sound authoritarian....
or religious. Sorry if I did sound pontifical.

No, it was the Debian guy who sounded funny.

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

On Wednesday 18 July 2001 18:03, Bruce Momjian wrote:

The strange part is that we are running around trying to figure out if
it is a bug and no one knows that Debian has modified it.

While I understand Oliver's reasons for having the Debian stuff on the debian
server, I believe it would be appropriate to have the patchfile and the
various Debian README's available on the main postgresql site.

It was a hunch that sent me looking there -- I had read the Debian patchfile
before (about the 'peer' authentication deal), and apparently my subconscious
picked up on it.

The Red Hat stuff isn't a problem because you recoginize it as such.

The RPM has a rather distinctive footprint, yes....
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Lamar Owen <lamar.owen@wgcr.org> writes:

On Wednesday 18 July 2001 18:03, Bruce Momjian wrote:

The strange part is that we are running around trying to figure out if
it is a bug and no one knows that Debian has modified it.

While I understand Oliver's reasons for having the Debian stuff on the
debian server, I believe it would be appropriate to have the patchfile
and the various Debian README's available on the main postgresql site.

ISTM that it'd be a good thing if current versions of all the add-on
source files for both Debian and RedHat RPMs were part of our CVS tree
(perhaps in /contrib, perhaps somewhere else, but anyway in the tree).
Had I been able to find that "No database specified" string by grepping
the sources, I'd have been much less mystified. Likewise for the "peer"
question a week or two back, and the questions we sometimes get about
the behavior of startup scripts that aren't even part of our tarball.

This sort of thing is going to keep coming up, so we might as well admit
that we need to know what is in the RPMs.

Oliver, Lamar, what say you?

regards, tom lane

On Wednesday 18 July 2001 10:42 pm, Tom Lane wrote:

Lamar Owen <lamar.owen@wgcr.org> writes:

While I understand Oliver's reasons for having the Debian stuff on the
debian server, I believe it would be appropriate to have the patchfile
and the various Debian README's available on the main postgresql site.

ISTM that it'd be a good thing if current versions of all the add-on
source files for both Debian and RedHat RPMs were part of our CVS tree
(perhaps in /contrib, perhaps somewhere else, but anyway in the tree).
Had I been able to find that "No database specified" string by grepping
the sources, I'd have been much less mystified. Likewise for the "peer"
question a week or two back, and the questions we sometimes get about
the behavior of startup scripts that aren't even part of our tarball.

Deja vu... didn't we have this discussion a month or two back?? :-) (
http://fts.postgresql.org/db/mw/msg.html?mid=115437#thread )

I'm all for it for the RPM's, at least, if others are game. We left off with
the question of where it would best be stored....

There is, in fact, an outstanding issue with the RPM initscript that I'm
still working on -- the 'sometimes I get a failure that isn't really a
failure' deal....I can't reproduce it.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Lamar Owen <lamar.owen@wgcr.org> writes:

On Wednesday 18 July 2001 10:42 pm, Tom Lane wrote:

ISTM that it'd be a good thing if current versions of all the add-on
source files for both Debian and RedHat RPMs were part of our CVS tree

Deja vu... didn't we have this discussion a month or two back?? :-) (
http://fts.postgresql.org/db/mw/msg.html?mid=115437#thread )

Yeah, we did. You seemed willing, but there was a notable silence
from the Debian quarter.

regards, tom lane

On Thu, Jul 19, 2001 at 12:11:47AM -0400, Tom Lane wrote:

Lamar Owen <lamar.owen@wgcr.org> writes:

On Wednesday 18 July 2001 10:42 pm, Tom Lane wrote:

ISTM that it'd be a good thing if current versions of all the add-on
source files for both Debian and RedHat RPMs were part of our CVS tree

Deja vu... didn't we have this discussion a month or two back?? :-) (
http://fts.postgresql.org/db/mw/msg.html?mid=115437#thread )

Yeah, we did. You seemed willing, but there was a notable silence
from the Debian quarter.

There have been discussions in the past on the debian mailing lists about
whether it is a good idea for upstream sources to include the debian patch.
The gist of it that since debian builds packages based on a pristine source
tar ball and a patch, if the patch were upstream, would the patch have to
patch its own upstream version?

If however they were merely stored in contrib/distributions/patches or some
such and there was an understanding that that may not match what is
currently available from debian, then I see no problem.

--
Martijn van Oosterhout <kleptog@svana.org>
http://svana.org/kleptog/

Tom Lane writes:

ISTM that it'd be a good thing if current versions of all the add-on
source files for both Debian and RedHat RPMs were part of our CVS tree

If you want to take the job of keeping these up to date or the job of
convincing all the 143 package developers out there to do that...

All of these package files are in a CVS tree somewhere (or should be), and
I would be happy to provide you with the links I use to poke around them
on occasion, but it should not be our job to keep track of the fancies of
operating system developers.

--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter

On Friday 20 July 2001 10:05, Peter Eisentraut wrote:

Tom Lane writes:

ISTM that it'd be a good thing if current versions of all the add-on
source files for both Debian and RedHat RPMs were part of our CVS tree

If you want to take the job of keeping these up to date or the job of
convincing all the 143 package developers out there to do that...

That would be my job to do for the RPM's, right? :-) I'm already keeping
them up -- and I know how to use CVS to do it, having commit access on a
couple of other projects.

Let me just say on thing about 'our' RPMs -- they are intended as a
semi-standard base from which OS distributors may make their own packages,
for which they are responsible. A side benefit is that people can grab the
latest hopefully-generic RPMset from us if their OS vendor isn't forthcoming
with updated packages.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Deja vu... didn't we have this discussion a month or two back?? :-) (
http://fts.postgresql.org/db/mw/msg.html?mid=115437#thread )

I'm all for it for the RPM's, at least, if others are game. We left off with
the question of where it would best be stored....

There is, in fact, an outstanding issue with the RPM initscript that I'm
still working on -- the 'sometimes I get a failure that isn't really a
failure' deal....I can't reproduce it.

Let me add that Red Hat is now distributing a different RPM with their
Red Hat Database, or at least I think they are. Can someone confirm?

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

Tom Lane writes:

ISTM that it'd be a good thing if current versions of all the add-on
source files for both Debian and RedHat RPMs were part of our CVS tree

If you want to take the job of keeping these up to date or the job of
convincing all the 143 package developers out there to do that...

All of these package files are in a CVS tree somewhere (or should be), and
I would be happy to provide you with the links I use to poke around them
on occasion, but it should not be our job to keep track of the fancies of
operating system developers.

I am slightly concerned about bloating our CVS tree.

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

On Friday 20 July 2001 11:24, Bruce Momjian wrote:

Let me add that Red Hat is now distributing a different RPM with their
Red Hat Database, or at least I think they are. Can someone confirm?

Trond may be able to.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Lamar Owen <lamar.owen@wgcr.org> writes:

On Friday 20 July 2001 11:24, Bruce Momjian wrote:

Let me add that Red Hat is now distributing a different RPM with their
Red Hat Database, or at least I think they are. Can someone confirm?

Trond may be able to.

The rpms of the Red Hat database are called rhdb, to avoid confusion.

--
Trond Eivind Glomsr�d
Red Hat, Inc.

On Friday 20 July 2001 11:25, Bruce Momjian wrote:

I am slightly concerned about bloating our CVS tree.

[lowen@utility pgsql]$ du -s *
4 COPYRIGHT
20 CVS
276 ChangeLogs
4 GNUmakefile.in
124 HISTORY
36 INSTALL
4 Makefile
4 README
4 aclocal.m4
160 config
240 configure
36 configure.in
3520 contrib
7196 doc
4 register.txt
30128 src
[lowen@utility pgsql]$

The RPM additions are:
56 contrib-intarray.tar.gz
4 file-lists.tar.gz
180 jdbc7.0-1.1.jar
92 jdbc7.1-1.2.jar
8 migration-scripts.tar.gz
4 postgresql-7.1.plperl.patch
4 postgresql-7.1.s390x.patch
4 postgresql-bashprofile
4 postgresql-dump.1.gz
8 postgresql.init
20 README.rpm-dist
4 rh-pgdump.sh
8 rpm-pgsql-7.1.patch

Of which the two jar files are derived from the source and wouldn't be
necessary. This totals 124K if I've done my math right.

The contrib-intarray.tar.gz is a new intarray from Red Hat -- I really need
to investigate this more closely....

'file-lists.tar.gz' may go away if I don't need to support older SuSE
distributions.

'migration-scripts.tar.gz' is a packaging of a few scripts used to perform a
dump using saved binaries from the previous installation.

The .patch files are system-specific and RPM-specific patches that probably
are not necessary to be applied to the main tree, as they mostly involve
paths (particularly for the regression tests), with the exception of the s390
patch. I can send these patches to the list easily enough -- the s390 patch
is also a Red Hat contribution.

'postgresql-bashprofile' is a .bashprofile placed into $PGDATA during RPM
installation (and, yes, unless someone goes and changes it the default shell
for the 'postgres' user is installed as bash).

'postgresql-dump.1.gz' is a man page for 'postgresql-dump' -- part of the
migrations-scripts tarball.

'rh-dump.sh' is another migration script that I really should fold into the
migrations-scripts tarball.... Although any of these migration scripts are a
mite cantankerous, as a pg_dumpall from 6.5.x to be restored on 7.1.x has
been shown to fail in certain instances (documented in the archives). Most
noticeable is the '60 minute' problem in 6.5's time types. 7.1.x takes a 6.5
dump a little easier than 7.0 did, though, IME.

'postgresql.init' is the initscript installed into
/etc/rc.d/init.d/postgresql.

'README.rpm-dist' tries to document the RPM differences and _why_ there are
RPM differences in the first place. While I technically _could_ patch the
installed SGML documentation sources to reflect the RPM installation, I have
not yet done so. README.rpm-dist is also available for perusal via the
website as
http://www.postgresql.org/ftpsite/binary/v7.1.2/RPMS/README.rpm-dist linked
off of http://www.postgresql.org/sites.html .

I'll be happy to document or discuss any of these files with anyone.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

On Friday 20 July 2001 11:25, Bruce Momjian wrote:

I am slightly concerned about bloating our CVS tree.

The RPM additions are:
56 contrib-intarray.tar.gz
4 file-lists.tar.gz
180 jdbc7.0-1.1.jar
92 jdbc7.1-1.2.jar
8 migration-scripts.tar.gz
4 postgresql-7.1.plperl.patch
4 postgresql-7.1.s390x.patch
4 postgresql-bashprofile
4 postgresql-dump.1.gz
8 postgresql.init
20 README.rpm-dist
4 rh-pgdump.sh
8 rpm-pgsql-7.1.patch

Of which the two jar files are derived from the source and wouldn't be
necessary. This totals 124K if I've done my math right.

Bag the JAR's and it looks fine.

The contrib-intarray.tar.gz is a new intarray from Red Hat -- I really need
to investigate this more closely....

Can you research that? Why are they doing it?

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

On Friday 20 July 2001 12:03, Bruce Momjian wrote:

The contrib-intarray.tar.gz is a new intarray from Red Hat -- I really
need to investigate this more closely....

Can you research that? Why are they doing it?

It looks like the updated intarray from Oleg. The diff between what is in the
7.1.2 tarball (which is the same as what is in current CVS) is 26K (the whole
intarray directory du's at 192K), and appears to be extensive in nature, with
a warning that this is _only_ for PostgreSQL 7.1 and above. Diff to 7.1.2
attached.

Oleg announced the new intarray in this message:
http://fts.postgresql.org/db/mw/msg.html?mid=120655 and there was discussion
following. But I don't see this version in CURRENT CVS??? Hmmm.... I don't
see the README changes in current CVS, but I do see the code changes....

The contrib support in the RPMset is fairly new, and Trond made this change
that I synced in place. Should I not ship the updated intarray?
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Lamar Owen writes:

The RPM additions are:
56 contrib-intarray.tar.gz
4 file-lists.tar.gz
8 migration-scripts.tar.gz

No tar or gz files in CVS.

4 postgresql-7.1.plperl.patch
4 postgresql-7.1.s390x.patch

No patches in CVS.

4 postgresql-bashprofile

Not sure what's in there exactly, so I can't comment.

4 postgresql-dump.1.gz

What's wrong with pg_dump?

8 postgresql.init

We already have one of those.

4 rh-pgdump.sh

See above.

8 rpm-pgsql-7.1.patch

See above.

See, if we want to get into the packaging business for real, then there
should not be any patches or extra programs or extra features distributed.
Fixes should be incorporated, not archived.

Then again, there are at least six other packaging efforts out there which
come with yet another set of patches and what not so I see this getting
messy.

--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter

Lamar Owen <lamar.owen@wgcr.org> writes:

The contrib-intarray.tar.gz is a new intarray from Red Hat -- I really need
to investigate this more closely....

Seems like that should go into our regular contrib tree.

The .patch files are system-specific and RPM-specific patches that
probably are not necessary to be applied to the main tree, as they
mostly involve paths (particularly for the regression tests), with the
exception of the s390 patch. I can send these patches to the list
easily enough -- the s390 patch is also a Red Hat contribution.

Portability patches also seem like they should go into the main sources.

regards, tom lane

On Friday 20 July 2001 12:30, Peter Eisentraut wrote:

Lamar Owen writes:

8 migration-scripts.tar.gz

No tar or gz files in CVS.

That's easy enough to fix.

4 postgresql-7.1.plperl.patch
4 postgresql-7.1.s390x.patch

No patches in CVS.

Then the configure system needs to support an optional FHS-compliant mode, as
well as alternative builds for plperl.... :-) The biggest patching by far is
in the regression tests, which really are not designed to live outside the
source tree, but can be munged into shape fairly easily.

Why no patches in CVS? How do you propose to handle the differences,
particularly if the debian stuff is placed in CVS (that diff is 10,884 lines
and 362,119 bytes in length)?

4 postgresql-dump.1.gz

What's wrong with pg_dump?

It only uses the current executables. After an 'rpm -U' older executables
are kept around by the server subpackage's %pre scriptlet, and
postgresql-dump/rh-dump massage the ld envvars to force execution of those
binaries to take a dump of the old database. If a good upgrade path existed,
this kludge would be unnecessary.

8 postgresql.init

We already have one of those.

That is too generic. This one is rather simple and is designed to work well
in the FHS-compliant environment, without lots of guessing where things are
-- the RPMset has a rigid structure where no guesswork is really necessary
(except for the location of documentation, which changes from dist to dist).
This one also automatically initdb's for you in the correct (for the RPMset)
place and with saving of locale values, etc, for later use, making sure to
start the postmaster with the same locale as initdb was executed with...
amongst other things.

If an older database is found, a message pointing to the README.rpm-dist is
supplied, and postmaster is not started.

See, if we want to get into the packaging business for real, then there
should not be any patches or extra programs or extra features distributed.
Fixes should be incorporated, not archived.

Then there needs to be a little more willingness to accept patches which
provide FHS-compliance (as an option). So your opinion is that we're not
really in the packaging business, right? Or am I misunderstanding that?

Should package-specific programs be distributed as part of the tarball that
everyone downloads? Not likely.

Being in CVS != being in the tarball(s), does it?

And having the spec file (which I inadvertently omitted above -- it's another
30k or so) in CVS would be a real boon to many.

Then again, there are at least six other packaging efforts out there which
come with yet another set of patches and what not so I see this getting
messy.

Six? I know of PLD's difference, and SuSE's difference -- but both of them
have synced with our set periodically. There's four others? Or are you
referring to non-RPM packages, such as Cygwin, Debian, and (four others)?

Hey, I'm fine either way -- it was Tom's suggestion, in order to help all the
developers out, not just me. It matters little to me if it's in the
postgresql.org CVS or not -- but it could help him and others track stuff
down (recursive grep with error messages, for instance).

Point being that bug reports that involve changes to the core code by
packages are happening, and confusion has resulted. A solution needs to be
found -- and, frankly, the packages aren't going away.

I'm going to go back two and a half years and re-read the stuff that lead up
to me fielding this particular portion of our development, to refresh my
perspective.....
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Lamar Owen <lamar.owen@wgcr.org> writes:

Oleg announced the new intarray in this message:
http://fts.postgresql.org/db/mw/msg.html?mid=120655 and there was
discussion following. But I don't see this version in CURRENT CVS???

I believe the state of play is that we have some catalog-changing work
to do to support GIST (ie, make "haskeytype" work cleanly), and merging
the updated intarray code is on hold until that gets done --- hopefully,
early next month. We're probably not exactly in sync with what Oleg
has, but I'm not worried about it until the GIST dust settles.

I dunno whether it makes sense to be shipping the updated intarray code
with 7.1; does it work properly in 7.1? Ask Oleg ...

regards, tom lane

Lamar Owen <lamar.owen@wgcr.org> writes:

The biggest patching by far is
in the regression tests, which really are not designed to live outside the
source tree, but can be munged into shape fairly easily.

Peter has already done good work in making it possible to build outside
the source tree. ISTM that it would make logical sense to allow
regression tests to be run outside the source tree as well, as long as
the changes don't break the existing procedures. I have not looked at
your patches in this area --- what do they need to do, exactly?

Being in CVS != being in the tarball(s), does it?

Yes. When this was discussed last time, I think the conclusion was that
packaging scripts should be in a different cvs module from the core
sources.

I think there are really two separate discussions going on here: one is
whether we shouldn't try harder to roll some of the RPMset diffs back
into the main sources, and the other is how we can make information
about some of the popular packages more readily visible/available to the
developers. Peter's stance on the latter seems to be "go look at the
packagers' sites", which is defensible, but that's the current approach
and I think it's not working. Leastwise I sure have no idea what's in
the packages. If I can pull down one additional CVS module from hub.org
and include that in my Postgres glimpse searches, I am actually likely
to expend that much effort, and as a result will be a lot better
informed.

Point being that bug reports that involve changes to the core code by
packages are happening, and confusion has resulted. A solution needs to be
found -- and, frankly, the packages aren't going away.

Exactly.

regards, tom lane

[cc: to GENERAL replacedby cc: to HACKERS]
On Friday 20 July 2001 17:14, Tom Lane wrote:

Lamar Owen <lamar.owen@wgcr.org> writes:

The biggest patching by far is
in the regression tests, which really are not designed to live outside
the source tree, but can be munged into shape fairly easily.

Peter has already done good work in making it possible to build outside
the source tree. ISTM that it would make logical sense to allow
regression tests to be run outside the source tree as well, as long as
the changes don't break the existing procedures. I have not looked at
your patches in this area --- what do they need to do, exactly?

Ok, let's look.  First, there is a createlang issue: during build, @libdir@ 
as referenced in the createlang script references /usr/lib, instead of 
/usr/lib/pgsql, which is desired.  So the first patch is:
diff -uNr postgresql-7.1.2.orig/src/bin/scripts/createlang.sh 
postgresql-7.1.2/src/bin/scripts/createlang.sh
--- postgresql-7.1.2.orig/src/bin/scripts/createlang.sh	Sun Feb 18 13:34:01 
2001
+++ postgresql-7.1.2/src/bin/scripts/createlang.sh	Wed Jun 13 16:00:55 2001
@@ -164,7 +164,7 @@
 # Check that we have PGLIB
 # ----------
 if [ -z "$PGLIB" ]; then
-	PGLIB='@libdir@'
+	PGLIB='/usr/lib/pgsql'
 fi

# ----------

To handle that, as $PGLIB does indeed point to /usr/lib/pgsql for most
things, but a user is not guaranteed to set the envvar. @libdir@ points to
/usr/lib during the build, as it should -- but createlang's PGLIB and
autoconf's libdir are not equal.

This is desireable because the procedural languages aren't generally loadable
into any arbitrary program by ld.so; rather, they are postgresql-specifc
modules, warranting a separate directory under FHS. This patch fixes the
RPM-specific case only, obviously, as /usr/lib/pgsql is going to be the wrong
choice for non-RPM users :-).

Next, we have patches to make the perl client honor RPM_BUILD_ROOT (otherwise
known as DESTDIR). I'm omitting them here, as Peter has mentioned a build
overhaul for the perl and python clients to make them do DESTDIR and in
general fit in better with the rest of the package.

On to the next batch.... There are a few perl and python scripts shipped as
examples -- every last one of them shebangs to '/usr/local/perl' or
'/usr/local/python' -- to make them usable, I patch this to '/usr/bin/perl'
or python, as appropriate. I only ship
postgresql-7.1.2/src/interfaces/perl5/test.pl at this time.

Now to the regression tests.  First off, I:
diff -uNr postgresql-7.1.2.orig/src/test/regress/GNUmakefile 
postgresql-7.1.2/src/test/regress/GNUmakefile
--- postgresql-7.1.2.orig/src/test/regress/GNUmakefile	Wed Apr  4 17:15:56 
2001
+++ postgresql-7.1.2/src/test/regress/GNUmakefile	Wed Jun 13 16:00:55 2001
@@ -67,8 +67,8 @@
 abs_builddir := $(shell pwd)

 define sed-command
-sed -e 's,@abs_srcdir@,$(abs_srcdir),g' \
-    -e 's,@abs_builddir@,$(abs_builddir),g' \
+sed -e 's,@abs_srcdir@,/usr/lib/pgsql/test/regress,g' \
+    -e 's,@abs_builddir@,/usr/lib/pgsql/test/regress,g' \
     -e 's/@DLSUFFIX@/$(DLSUFFIX)/g' $< >$@
 endef

since the tests aren't in the build tree anymore, but in
/usr/lib/pgsql/test/regress. Well _technically_ they're really NOT in
/usr/lib/pgsql/test/regress, but in DESTDIR/usr/lib/pgsql/test/regress during
the build -- but they will be executed in the coded location after the RPM
installation.

Then, I:
-   AS '@abs_builddir@/regress@DLSUFFIX@'
+   AS '/usr/lib/pgsql/test/regress/regress.so'
everywhere that is used, along with its likenesses pointing to refint.so and 
autoinc.so, which I prebuild and stuff into /usr/lib/pgsql/test/regress.  
Although /usr/lib/pgsql would be a more consistent place, I guess.  That 
construct is used in 
postgresql-7.1.2/src/test/regress/input/create_function_1.source and 
ostgresql-7.1.2/src/test/regress/output/create_function_1.source.

Finally, I patch postgresql-7.1.2/src/test/regress/pg_regress.sh:
@@ -69,7 +69,7 @@
: ${inputdir=.}
: ${outputdir=.}

-libdir='@libdir@'
+libdir='/usr/lib/pgsql'
bindir='@bindir@'
datadir='@datadir@'
host_platform='@host_tuple@'

Again, @libdir@ != $PGLIB.

This set is quite a bit smaller than the 7.0.x and 6.5.x sets, thanks in no
small part to Peter's work, as you have already said.

I think there are really two separate discussions going on here: one is
whether we shouldn't try harder to roll some of the RPMset diffs back
into the main sources, and the other is how we can make information
about some of the popular packages more readily visible/available to the
developers.

My diffs are nowhere near as large as the debian set. There are other things
I could patch, instead of frobbing in the specfile, though -- things like the
python and perl clients' makefile's DESTDIR ignorance, and the fact that
'make install' puts the procedural languages in /usr/lib instead of
/usr/lib/pgsql. The easy answer: 'Use the --libdir configure switch!' won't
work, though, as I can't just tell configure that libdir needs to be
/usr/lib/pgsql -- libpq.so and friends need to go in /usr/lib!

And I've not tried to make my patches fit the general case as yet -- they
haven't needed to be general in scope.

There is some munging done in contrib that could be put in a patch, though --
in particular, the following construct executes _14_ times....
# some-contrib-module
pushd some-contrib-module
perl -pi -e "s|/usr/lib/contrib|/usr/lib/pgsql/contrib/some-contrib-module|" *
popd

libdir !=$PGLIB, again.

And more path munging for the rserv and earthdistance contrib modules happen.

And the whole contrib tree, since there isn't a good 'make install' that
honors DESTDIR for that tree, gets a kick in the pants to
/usr/lib/pgsql/contrib, from $RPM_BUILD_DIR/postgresql-7.1.2.

Peter's stance on the latter seems to be "go look at the
packagers' sites", which is defensible, but that's the current approach
and I think it's not working.

The biggest RPM difference is simply where things are put. Otherwise there's
a mere handful of sysadmin scripts added.

With the specfile, README.rpm-dist, and the other scriptfiles in a CVS
module, I'd sleep better, knowing that someone else might have an easier time
picking things up if I kick the big bucket.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Lamar Owen <lamar.owen@wgcr.org> writes:

Ok, let's look. First, there is a createlang issue: during build, @libdir@
as referenced in the createlang script references /usr/lib, instead of
/usr/lib/pgsql, which is desired.

Okay, that problem is gone in current sources, anyway (createlang no
longer needs to know any absolute paths).

On to the next batch.... There are a few perl and python scripts shipped as
examples -- every last one of them shebangs to '/usr/local/perl' or
'/usr/local/python' -- to make them usable, I patch this to '/usr/bin/perl'
or python, as appropriate.

Hmm. Given that they're only examples, and are clearly going to be
broken until hand-edited on many systems not only RedHat, it's not clear
that this is worth your worrying about. But by the same token, I
wouldn't have a problem with applying that change to the masters ---
surely there are as many systems where '/usr/bin/perl' is correct as
there are where the other is correct. (In fact, a quick grep shows that
we have more '/usr/bin/perl' than '/usr/local/bin/perl' in the
distribution, so your claim that they're all the latter is mistaken.
We should certainly try to make them consistent, whichever is
preferred.)

BTW, the only python shebangs I can find in CVS look like
#! /usr/bin/env python
Isn't that OK on RedHat?

Now to the regression tests.  First off, I:
define sed-command
-sed -e 's,@abs_srcdir@,$(abs_srcdir),g' \
-    -e 's,@abs_builddir@,$(abs_builddir),g' \
+sed -e 's,@abs_srcdir@,/usr/lib/pgsql/test/regress,g' \
+    -e 's,@abs_builddir@,/usr/lib/pgsql/test/regress,g' \
-e 's/@DLSUFFIX@/$(DLSUFFIX)/g' $< >$@
endef

Clearly, this needs to be generalized ...

Then, I:
-   AS '@abs_builddir@/regress@DLSUFFIX@'
+   AS '/usr/lib/pgsql/test/regress/regress.so'
everywhere that is used, along with its likenesses pointing to refint.so and 
autoinc.so, which I prebuild and stuff into /usr/lib/pgsql/test/regress.  

Much of this could be eliminated given the new path-searching behavior
for CREATE FUNCTION, I think. Actually I thought Peter had cleaned it
up already, but I see he hasn't touched the regression tests. IMHO we
could have "make installcheck" copy the .so files to $LIBDIR, and then
the regression test input and output files themselves wouldn't need to
know these paths at all. (OTOH, there'd still be paths in the COPY
commands. Would it be okay to eliminate testing of backend COPY and
instead make these regression tests use psql \copy?)

regards, tom lane

Tom Lane <tgl@sss.pgh.pa.us> writes:

BTW, the only python shebangs I can find in CVS look like
#! /usr/bin/env python
Isn't that OK on RedHat?

It is.

--
Trond Eivind Glomsr�d
Red Hat, Inc.

On Fri, Jul 20, 2001 at 07:05:46PM -0400, Trond Eivind Glomsr?d wrote:

Tom Lane <tgl@sss.pgh.pa.us> writes:

BTW, the only python shebangs I can find in CVS look like
#! /usr/bin/env python
Isn't that OK on RedHat?

It is.

Probably the perl scripts should say, likewise,

#!/usr/bin/env perl

Nathan Myers
ncm@zembu.com

Bruce Momjian <pgman@candle.pha.pa.us> writes:

On Friday 20 July 2001 11:25, Bruce Momjian wrote:

I am slightly concerned about bloating our CVS tree.

The RPM additions are:
56 contrib-intarray.tar.gz
4 file-lists.tar.gz
180 jdbc7.0-1.1.jar
92 jdbc7.1-1.2.jar
8 migration-scripts.tar.gz
4 postgresql-7.1.plperl.patch
4 postgresql-7.1.s390x.patch
4 postgresql-bashprofile
4 postgresql-dump.1.gz
8 postgresql.init
20 README.rpm-dist
4 rh-pgdump.sh
8 rpm-pgsql-7.1.patch

Of which the two jar files are derived from the source and wouldn't be
necessary. This totals 124K if I've done my math right.

Bag the JAR's and it looks fine.

The contrib-intarray.tar.gz is a new intarray from Red Hat -- I really need
to investigate this more closely....

Can you research that? Why are they doing it?

It's a new one from upstream - it fixed some bugs, AFAIK.

--
Trond Eivind Glomsr�d
Red Hat, Inc.

On Friday 20 July 2001 18:45, Tom Lane wrote:

Lamar Owen <lamar.owen@wgcr.org> writes:

On to the next batch.... There are a few perl and python scripts shipped
as examples -- every last one of them shebangs to '/usr/local/perl' or
'/usr/local/python' -- to make them usable, I patch this to
'/usr/bin/perl' or python, as appropriate.

Hmm. Given that they're only examples, and are clearly going to be
broken until hand-edited on many systems not only RedHat, it's not clear

Well, there were more than just a few at one point. In any case, it's been
awhile since I combed through the example scripts -- of which I only now ship
the one, which is designed to test the perl client -- which I find to be a
useful thing.

BTW, the only python shebangs I can find in CVS look like
#! /usr/bin/env python
Isn't that OK on RedHat?

Yeah, that construct is OK. 7.0.x was different, unless I'm far off-base.
But I'm not shipping any patched python scripts with 7.1.x anyway -- the
6.5.x and 7.0.x dists had some scripts with #!/usr/local/bin/python.

So much for my 'every last one,' eh? :-)

Much of this could be eliminated given the new path-searching behavior
for CREATE FUNCTION, I think. Actually I thought Peter had cleaned it
up already, but I see he hasn't touched the regression tests.

How is this search path defined? Blindly using libdir is not ok --
libdir!=PGLIB, and PGLIB may not be defined in the environment -- it might be
there, but we can't count on it.

IMHO we
could have "make installcheck" copy the .so files to $LIBDIR,

libdir!=PGLIB for the RPMs. libdir=/usr/lib; PGLIB=/usr/lib/pgsql. I was so
happy when the bki sources were no longer referenced by PGLIB -- when the
procedural language handlers aren't thusly referenced will be a Happy Day.
If PGLIB could = libdir, and something like PGHANDLER= where the handlers
live, I'd also be happy. If this function search path can be configured to
search in /usr/lib/pgsql and all or any of its subs, while libpq and kin live
in /usr/lib, I _will_ be happy.

and then
the regression test input and output files themselves wouldn't need to
know these paths at all. (OTOH, there'd still be paths in the COPY
commands. Would it be okay to eliminate testing of backend COPY and
instead make these regression tests use psql \copy?)

The COPY paths are munged into form by the GNUmakefile patch -- so, if the
GNUmakefile can generally deal with the paths by placing relative paths
(relative to what, though?) in the @abs_srcdir@/@abs_builddir@ substitutions,
then those paths aren't an issue.

Although a psql \copy regression test might be a good thing in its own right.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Lamar Owen <lamar.owen@wgcr.org> writes:

How is this search path defined? Blindly using libdir is not ok --

Why not?

The search path is defined in postgresql.conf (and I see Peter forgot
to add an example to the postgresql.conf.sample file), but the default
is the backend-compile-time $libdir. Offhand I don't see what's wrong
with it.

libdir!=PGLIB, and PGLIB may not be defined in the environment -- it
might be there, but we can't count on it.

AFAICT we do not depend on environment PGLIB any more. Configure-time
$libdir is what counts.

If this function search path can be configured to search in
/usr/lib/pgsql and all or any of its subs, while libpq and kin live in
/usr/lib, I _will_ be happy.

I think all you need to do is set up postgresql.conf that way.

regards, tom lane

On to the next batch.... There are a few perl and python scripts shipped as
examples -- every last one of them shebangs to '/usr/local/perl' or
'/usr/local/python' -- to make them usable, I patch this to '/usr/bin/perl'
or python, as appropriate.

Hmm. Given that they're only examples, and are clearly going to be
broken until hand-edited on many systems not only RedHat, it's not clear
that this is worth your worrying about.

Ack! There is a way to write this stuff to be portable. The tricks
change a bit depending on the scripting language you are using, but for
perl this is how the header should look:

#!/bin/sh
# -*- perl -*-
# the line above helps with emacs, and put other comments here...

eval '(exit $?0)' && eval 'exec perl -S $0 ${1+"$@"}'
& eval 'exec perl -S $0 $argv:q'
if 0;

# real perl code follows...

There is no reason to have a dependency on anything but the location of
sh, which is much more reliable than locations for perl, tcl, etc etc.
Not sure the exact form of this technique for python (maybe the same as
above) but there is a similar but not identical form for tcl code
(examples available on request; the above for perl is demonstrated in
contrib/rserv/*.in).

- Thomas

On Friday 20 July 2001 19:56, Tom Lane wrote:

Lamar Owen <lamar.owen@wgcr.org> writes:

How is this search path defined? Blindly using libdir is not ok --

Why not?

During RPM build, libdir will point to /usr/lib. This is OK and appropriate
for the generally-loadable shared libs. HOWEVER, the shared objects that are
affected by this function handler load search path will not be located in
/usr/lib -- as they are not generally loadable shared libraries, but
PostgreSQL-only shared libraries. Thus, /usr/lib/pgsql is the home for
those, and, in an RPM installation, should be the head of any shared object
load path searched by the PostgreSQL dynaloader.

/usr/lib -> system dynaloader default for non-essentials (/lib of course for
libs essential for boot)
/usr/lib/pgsql -> PostgreSQL dynaloader default (ideally, on an FHS-compliant
installation).

The search path is defined in postgresql.conf (and I see Peter forgot
to add an example to the postgresql.conf.sample file), but the default
is the backend-compile-time $libdir. Offhand I don't see what's wrong
with it.

I can patch postgresql.conf.sample easily enough -- but, if I'm trying to get
away from RPM-specific patches.... :-) I have heretofore not modified the
default postgresql.conf in anyway -- no tuning, no tcpip_socket setting (for
which I get some grief, as people running RPMs of 7.0.x are used to -i being
on by default), no nothing.

Not knowing alot about autoconf, I hesitate to suggest or ask the following,
but I will anyway -- is it possible to define an optional
'so-search-path-default' switch for the backend's dynaloader? This has
nothing to do with the OS dynaloader path, for which there is a well-defined
config file on most OS's -- just the backend's function handler dynaloader.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11