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
