Re: Makefile.global will override configure parameters if "pgsql" and "postgres" appear anywhere in the source path name

Hi,

On 2022-07-15 19:22:12 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2022-07-15 20:38:17 +0200, Alvaro Herrera wrote:
> >> Right.  See commit 984b0b4df83f and its discussion at [1].  The working
> >> theory (as I remember it) is that if the installation is already
> >> postgres-specific (because the user has made it so by having "pgsql" or
> >> "postgres" in the argument to --prefix), then we don't need to add
> >> another level of postgres-specificity to it; but otherwise we add
> >> "/postgresql" to the path so that the resulting files don't end up mixed
> >> with files installed by unrelated packages.
> 
> > I think the current approach isn't great.
> 
> > E.g., putting extension .so's into the same directories as "normal shared
> > libraries", which typically is either in the library search path via system
> > configuration, or in the library search path due to rpath, strikes me as quite
> > wrongheaded.
> 
> Well, we don't, with a normal not-PG-specific install path.

Right - I was commenting on the "postgres"/"pgsql" specific logic.


> which seems perfectly sane from here.  The issue is that if the
> install directory path already has "postgres" somewhere in it,
> you get a different layout where the PG-specific subdir is smashed
> together with the user libraries.
> 
> I tend to agree with the OP that that case isn't great, but we've
> had it like this for so long that I'm not sure we can change it.
> OTOH, the issue probably only affects PG developers, so maybe
> we could?

I'm not sure it just devs - I think several distribution install things into
per-major-version paths containing postgres or pgsql. But I think they also
tend to patch postgres to avoid some of the Makefile.global magic. So I
suspect it'd not be too hard for them to adjust.

Greetings,

Andres Freund