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
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 |