> Mark Woodward wrote:
>
>> As a guy who administers a lot of systems, sometimes over the span of
>> years, I can not understate the need for "a" place for the admin to
>> find
>> what databases are on the machine and where they are located.
>>
>> Your assertion that this file would "only works for one root-made
>> installation on a single filesystem layout" totally misses the point.
>> The
>> point is that me, a consultant, could find where the database is,
>> easily.
>> Given a large system, say it has 3 or 4 separate databases on it. How do
>> you know which is what?
>>
>
> I think you make a good point. However you probably need to include the
> location of the server software too (in case you run multiple versions).
> This means there really needs to be a standard location (e.g
> /usr/local/etc, /etc ...???? on win32) for this "cluster registration"
> file, and you need to list (at minimum):
>
> PGHOME
> DATADIR
> PORT
> USER
I'm not sure that I agree. At least in my experience, I wouldn't have more
than one installation of PostgreSQL in a production machine. It is
potentially problematic.
>
> As Tom hinted, to be effective, this would need to be maintained by the
> installation process, otherwise it is just another source of confusion
> (like the Oracle site I went to last year where they had an incorrect
> /etc/oratab - I wasted *hours* on that....)
At least with "oratab" using standards would help.
I can tell you, I have tried to find PostgreSQL installs after a power
outage and it is hell. If people know there is *a* standard and are
expected to use it, they will, they want their systems to run. As it is
PostgreSQL has no standard and provides no mechanism to do this.
---------------------------(end of broadcast)---------------------------
TIP 1: 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
