From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Andy Bailey <bailey(at)akamai(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: Makefile.global will override configure parameters if "pgsql" and "postgres" appear anywhere in the source path name |
Date: | 2022-07-15 23:30:27 |
Message-ID: | 20220715233027.txfjfeg3clqytdst@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Hi,
On 2022-07-15 19:22:12 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Walker Philips | 2022-07-15 23:37:47 | pg_catalog.pg_proc procedure has correct proargnames array, but proargtypes is empty |
Previous Message | Tom Lane | 2022-07-15 23:22:12 | Re: Makefile.global will override configure parameters if "pgsql" and "postgres" appear anywhere in the source path name |