On Sat, Jan 03, 2015 at 07:56:06PM -0500, Tom Lane wrote:
> Noah Misch <noah@leadboat.com> writes:
> > On Sat, Jan 03, 2015 at 02:36:50PM -0500, Noah Misch wrote:
> >> The directory libpq consults is `pg_config --sysconfdir`
>
> > I was wrong there. `pg_config --sysconfig` uses get_etc_path(), which adjusts
> > to post-installation moves of the installation tree. parseServiceInfo() uses
> > the build-time SYSCONFDIR directly.
>
> Ugh. That makes things messy. Still, we're probably better off
> recommending `pg_config --sysconfdir` than anything else.
Agreed; I can't see to do better.
> I doubt
> that the theoretical ability to do a post-installation move is used
> much, and it's certainly not used by people using a prepackaged build.
> So the recommendation would only be wrong for someone who had done such
> a move manually, and they'd probably know what to do anyway.
Relocatability sees regular use in binary distributions that target multiple
OS flavors. Installers available under the various "Graphical installer"
headings on our download pages do rely on it, and I bet Postgres.app does
likewise. All src/tools/msvc builds rely on it.
To add yet more to the mess, set_pglocale_pgservice() usually sets the
PGSYSCONFDIR environment variable to the result of get_etc_path(). As a
result, the client programs we ship do in practice use the relocation-aware
`pg_config --sysconfdir`. Third-party client programs do not. I'm
comfortable writing off that discrepancy as a limitation of such packaging
strategies. A packager wishing to compensate can make its installer write out
an environment script that sets PGSYSCONFDIR and encourage users to source that
script before starting libpq applications. I bet some installers already do
that for variables like LD_LIBRARY_PATH, in which case it's an easy addition.
> > More or less. I haven't tested, but I have no reason to suspect the relevant
> > parseServiceInfo() code behaves any differently. However, the value of
> > SYSCONFDIR is different depending on your choice of libpq build system:
>
> > gmake: same as non-Windows gmake build, based on "configure" arguments
> > src/tools/msvc: #define SYSCONFDIR "/etc"
> > win32.mak: #define SYSCONFDIR ""
> > bcc32.mak: #define SYSCONFDIR ""
>
> > A src/tools/msvc build, the most common case, would look relative to the root
> > of the current drive, e.g. X:/etc/pg_service.conf. Borland and nmake builds
> > would look for X:/pg_service.conf. (I doubt that reflects a coherent plan,
> > though I can't think of a single clearly-better location known at build time.)
>
> Yeah. We should make those builds all consistent IMO; the /etc case is
> probably the best one to standardize on.
Not the gmake/MinGW build, but one could make a fair argument for changing
win32.mak and bcc32.mak. If we were just now adding them for the first time,
we would certainly have them mimic src/tools/msvc. I have no idea who uses
those alternative libpq build systems these days. I don't know whether that
audience prefers compatibility with src/tools/msvc or compatibility with 9.4
and earlier of the same build system. So, while I too first thought to make
them consistent, I'll demur.