> 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?
