Re: Exposing an installation's default value of unix_socket_directory - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Exposing an installation's default value of unix_socket_directory
Date
Msg-id 13984.1289486730@sss.pgh.pa.us
Whole thread Raw
In response to Re: Exposing an installation's default value of unix_socket_directory  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Exposing an installation's default value of unix_socket_directory
Re: Exposing an installation's default value of unix_socket_directory
List 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 by date:

Previous
From: Dave Page
Date:
Subject: Re: improved parallel make support
Next
From: Itagaki Takahiro
Date:
Subject: MULTISET and additional functions for ARRAY