Tom Lane wrote: > Peter Eisentraut <pete...@gmx.net> writes: > > On tor, 2010-10-21 at 16:59 -0400, Tom Lane wrote: > >> Actually, the only reason this is even up for discussion is that > >> there's > >> no configure option to set DEFAULT_PGSOCKET_DIR. If there were, and > >> debian were using it, then pg_config --configure would tell what I > >> wish > >> to know. I thought for a bit about proposing we add such an option, > >> but given the current state of play it might be more misleading than > >> helpful: as long as distros are accustomed to changing this setting > >> via > >> a patch, you couldn't trust pg_config --configure to tell you what a > >> given installation actually has compiled into it. > > > Presumably, if a configure option were added, they couldn't change it > > via patch anymore. > > Hm, you're right: we'd remove the pg_config_manual.h entry, so the > existing patches would stop working, and presumably maintainers would > figure out that they ought to use the configure switch instead. So > that argument holds little water. > > > Btw., a configure option for this was rejected years ago to discourage > > people from actually changing the default. > > Yeah, I remember that discussion now that you mention it. It still > seems like a good policy ... but given that some popular packages are > changing the default whether we think it's a good idea or not, maybe > it's better to acknowledge that reality. We could still have some > text in the manual pointing out the compatibility hazards of using > the switch, I guess.
Might have been a nice change for 9.0. :-( I don't think there is a great amount of defense that it should be in /tmp except for backward compatibility, and for non-root installs. For a package installer, I think moving it out of temp makes sense, hence a configure flag. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers