pgsql@mohawksoft.com wrote:
> > The only other idea I can think of is to create a new pg_path.conf file.
> > It would have the same format as postgresql.conf, but contain
> > information about /data location, config file location, and perhaps
> > pg_xlog location.
> >
> > The file would be created by special flags to initdb, and once created,
> > would have to be used instead of pgdata for postmaster startup.
>
> That seems like a lot more risky, doesn't it? What is technically bad
> about my patch? Why is it "bad?" Everyone is offering something different
> than what I suggest. What is technically wrong with the patch? What can I
> alter to correct any concerns?
>
> I'm not a very good at politics, I sometimes tend to alianate people in
> discussions, but I am simply unable to understand why the features I
> suggest are not being considered "as is." I have been using them for a
> while now, I find them very useful, and I have people downloading the
> patch from my site on a regular basis. Yet I an unable to say "Here can we
> add this." The response is "We don't like this for x, y, and z," but
> reasons x, y, and z already exist in one form or another in the current
> implementation.
>
> (1) What tangable harm comes to postgresql.conf from these features?
> (2) What problem (security, stabilitry, safety, etc.) is created by these
> features that doesn't already exist in some form already.
> (3) Isn't having this as an option "better" than making it normal for
> people to mess around in the PGDATA directory?
> (4) Isn't open source and UNIX phylosophy about providing capability not
> enforcing policy?
I think the major problem with your -C & -D idea is that you require the
administrator to link the config file and data directory everytime you
start the db, and that might be error-prone.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073