On Thu, Feb 13, 2003 at 05:59:17PM -0500, Robert Treat wrote:
> On Thu, 2003-02-13 at 15:08, mlw wrote:
> > Stephan Szabo wrote:
> > 
> > On Thu, 13 Feb 2003, mlw wrote:
> > 
> > I have absolutely no problem debating and augmenting the feature. None
> > what so ever, I am more pushing to get momentum to actually do it. 
> Stick with it, I think most of us here can see the value in the option,
> but there are valid concerns that it be implemented correctly.
> Personally I think a postgresql installation is much more like an apache
> installation, which generally contains all of the files (data and
> config) under /usr/local/apache. Maybe someone can dig more to see if
> that system is more appropriate a comparison than something like bind.

        I think you are making a pretty uninformed, if not just plain wrong 
generalization.  I've run exactly one system with apache configuration 
files in /usr/local/apache, and even then, the data was not there.

        A quick straw poll of the people I know who actually do run real systems
also mentioned that they use packaging systems like encap or rpm to manage
upgrades, and would almost never put datafiles into /usr/local.

RedHat (7.3 at least)'s default httpd datafiles go in /var/www/html and
config goes in /etc/httpd

One OpenBSD user I talked to puts his in /home/www and config files in
/etc/httpd.  The defaults are /var/www and /var/www/conf

Another user reports:
On systems that I set up I have /web/{apache|httpd}/ and put all 
the config info there.
And /web/sites/name/ holds site data.

What does this mean?

People will put things in different places, and there are typically
very good reasons for this.  This is ESPECIALLY true when one wants to
have configuration files, at least the base ones in a common place such
as /etc or /usr/local/etc in order to make backup of configuration easy
and clean, while leaving data somewhere else for performance or magnitude
of partition reasons.  It just makes sense to ME to have postgresql.conf
reside in /etc, yet put my data in /var/data/postgresql, yet retain the
option to put my data in /raid/data/postgresql at a later date, when the
new hardware comes in.

Yes, symlinks are an option on most systems.  No, they are not a good
one on most systems.

What _I_ would like to see:

o. a default postgresql.conf location of $PREFIX/data/postgresql.conf
o. a default PGDATA location of whatever directory postgresql.conf is in
(this should maintain backward compatibility)
o. a ./configure - time option to override the location of the postgresql.conf
o. a run-time option to override the location of the postgresql.conf
o. options in postgresql.conf to specify the location of PGDATA and PID files.

($PREFIX is already settable at ./configure - time)

This would allow:
        o. Config files in /usr/local/pgsql/data, /etc, /usr/local/etc, ~postgresql, 
        or /dev/.hidden-node, whichever you prefer, so long as you either know
        the compile-time default, or are willing to specify it at startup.

        o. Datafiles to be in /usr/local/pgsql/data, /var/data, /raid0, /nfs/bigmount
        or whichever you prefer, so long as you either know the compile-time default,
        or are willing to specify it in a config file that you specify at startup.

Does it add complexity to the system?  Sure -- a very little bit, IMHO, especially
compared to the BTREE-folding that I see being bantered about.

Is it some work?  Sure -- a very little bit, and it seems that it has already
been done.

However, this seems, to me, to be a very small addition that has some real-world
(and yes, we need to start paying attention to the real world) advantages.

And finally, don't go telling me that I'm wrong to put my data and config files
where I am.  You can offer advice, but I'm probably going to ignore it because
I like where they are and don't need to explain why.

Adam Haberlach         | "Because manholes are round."
http://mediariffic.com |

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Reply via email to