Re: RFC: Additional Directory for Extensions - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: RFC: Additional Directory for Extensions
Date
Msg-id d0885e1f-3c0b-425f-a50c-2ba0fca1ce8a@dunslane.net
Whole thread Raw
In response to Re: RFC: Additional Directory for Extensions  (Robert Haas <robertmhaas@gmail.com>)
List 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
onehave 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’sset --- 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
pathfunctionality 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




pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: should we have a fast-path planning for OLTP starjoins?
Next
From: Robert Haas
Date:
Subject: Re: Add -k/--link option to pg_combinebackup