Re: Configurable path to look up dynamic libraries

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 15 May 2001 16:12, Tom Lane wrote:
> teg(at)redhat(dot)com (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes:
> >> The real bottom line here, though, is that you haven't shown me any
> >> positive reason to move the config files out of datadir.

> > It conflicts with the FHS -

> AFAIK, the FHS is not designed to support multiple instances of
> unprivileged daemons.

Really? I've never read that into the FHS.

A '/etc/pgsql' directory can easily accomodate multiple config files, or a
single config file with multiple sections. It can just as easily have a
whole tree of stuff under it. And it can be owned by a non-privileged user.
It just cannot be installed into without root's help -- and I know that that
is the main objection here.

But I have a hard time understanding this all-or-nothing approach. So what
if we have a configure-time option to allow a more FHS-compliant approach?
It won't interfere with the 'traditional' /usr/local/pgsql or /opt/pgsql or
whatever way of doing things. Further, it won't uglify the code in the least
- -- it just allows more choice. Further, it won't take a hacker long to make
it work. It won't even touch 'real' backend code, either -- this is a
postmaster thingy.

What's the opposition about? We have all the configure options already for
many things that the 'traditional' postgresql user cares nothing about.

But, on a more pragmatic note, I am contemplating the ability for the RPM's
initscript to allow multiple postmasters -- even up to sane behavior in the
presence of postmasters that it didn't start -- with multiple datadirs, etc.

I don't want the RPM's to 'editorialize' any more than anyone else might --
but unless a more FHS-compliant approach is at least _allowed_ (NOT
mandated!), I guess there will need to be some editorializing in the
intscript as it will have to place its own config file somewhere in order to
make multiple postmasters happen.

But I don't want to go through that if I don't have to -- or if it's going to
happen anyway.

And, I know, currently the '-D' postmaster directive does, indirectly, point
to the location of postgresql.conf..... :-) I will be using that in the
initscript's logic if another option isn't done.

But, if I may editorialize a little myself, this is just indicative of a
'Fortress PostgreSQL' attitude that is easy to get into. 'We've always done
it this way' or 'This is the way PostgreSQL works' are pat answers to
anything from 'Why can't I more smoothly upgrade?' to 'Why does PostgreSQL
use non-SQL-standard case-folding?' to 'Why does everything go in
/usr/local/pgsql?' to 'Do I _really_ have to do an ASCII dump of my 100GB
database in order to go to the next major version?' to any number of other
FAQ's.

Just because we've always done it one way does not that one way correct make.

We're one component of a system -- and the PostgreSQL Group has done such a
good job of being platform agnostic that the platform and systems issues are
almost second-class citizens.

Well, gotta get off the soap box now, and get to work producing some code, I
guess. People are going to be expecting multiple postmaster support in the
RPMset soon. :-)
- --
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7AZ+15kGGI8vV9eERAu+MAJ9bk8mY8n1qIk8zKqWM1K188/530wCeJnwd
ZZDjAosFhRnTENBWJ+THju4=
=mPC9
-----END PGP SIGNATURE-----