Re: RFC: Additional Directory for Extensions

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: "David E(dot) Wheeler" <david(at)justatheory(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Gabriele Bartolini <gabriele(dot)bartolini(at)enterprisedb(dot)com>, Craig Ringer <craig(dot)ringer(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Subject: Re: RFC: Additional Directory for Extensions
Date: 2025-02-04 20:34:36
Message-ID: d0885e1f-3c0b-425f-a50c-2ba0fca1ce8a@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 2025-02-03 Mo 3:42 PM, David E. Wheeler wrote:
> Hi Peter,
>
>> prefix= should only be set when running the "install" target, not when building (make all).
> I see. I confirm that works. Still, don’t all the other parameters work when passed to any/all targets? Should this one have an extension-specific name?

IDK, I don't understand what you think you're saying when you specify
--prefix to an extension build (as opposed to an install).

>
>>> So I suspect the issue is that, when looking for SQL files, the patch needs to use the directory parameter[4] when it’s set --- and it can be an absolute path! Honestly I think there’s a case to be made for eliminating that parameter.
>> Possibly. I didn't know why extensions would use that parameter, before you showed an example.
> ISTM it does more harm than good. The location of extension files should be highly predictable. I think the search path functionality mitigates the need for this parameter, and it should be dropped.

I agree that we should either drop the "directory" directive or fix this
patch so it doesn't break it. I have never used the directive, not sure
I was even aware of its existence, so I have no objection to dropping it.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2025-02-04 20:35:37 Re: Fix assert failure when decoding XLOG_PARAMETER_CHANGE on primary
Previous Message Joe Conway 2025-02-04 20:34:23 Re: should we have a fast-path planning for OLTP starjoins?