Re: Exposing an installation's default value of unix_socket_directory
От | Tom Lane |
---|---|
Тема | Re: Exposing an installation's default value of unix_socket_directory |
Дата | |
Msg-id | 13984.1289486730@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Exposing an installation's default value of unix_socket_directory (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: Exposing an installation's default value of
unix_socket_directory
Re: Exposing an installation's default value of unix_socket_directory |
Список | pgsql-hackers |
Peter Eisentraut <peter_e@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. regards, tom lane
В списке pgsql-hackers по дате отправления: