> 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? ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html