Re: Exposing an installation's default value of unix_socket_directory

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Exposing an installation's default value of unix_socket_directory
Date: 2010-11-11 14:45:30
Message-ID: 13984.1289486730@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Itagaki Takahiro 2010-11-11 15:02:52 MULTISET and additional functions for ARRAY
Previous Message Dave Page 2010-11-11 13:40:55 Re: improved parallel make support