Re: extension_control_path and "directory" - Mailing list pgsql-hackers

From Christoph Berg
Subject Re: extension_control_path and "directory"
Date
Msg-id aAjwPjsIElh17Nby@msg.df7cb.de
Whole thread Raw
In response to Re: extension_control_path and "directory"  (Matheus Alcantara <matheusssilv97@gmail.com>)
Responses Re: extension_control_path and "directory"
List pgsql-hackers
Re: Matheus Alcantara
> I've tried to implement some kind of "SHAREDIR search path" as we've
> discussed on another thread [1] but it shows out that we need some
> considerable refactoring to make it work.

Remembering which path the .control file was found in and from there
open the extension "directory" doesn't sound too hard. Why does it
have to be more complicated?

Also, re-running a search path discovery for the directory is probably
just wrong, if there are different extension versions in the "control"
search path and the "extensions" search path, it might lead to weird
version skew problems.

> Talking with Peter privately IIUC we concluded that we may document
> this limitation that using extension control path with an extension that
> uses a custom "directory" field on .control file will not work. I think
> that we may add a note section on "extension_control_path" doc on [2],
> what do you think?

Seen from Debian, this would be a regression since it worked with my
custom patch.

The number of extensions using that feature is limited, though, so it
wouldn't be a huge problem:

$ grep directory */*/*.control
pgfincore/pgfincore/pgfincore.control:directory = pgfincore
postgresql-pgmp/postgresql-pgmp/pgmp.control:directory = 'pgmp'
postgresql-semver/postgresql-semver/semver.control:directory = 'semver'

(Not including extensions generating the .control file at build time.)

Christoph



pgsql-hackers by date:

Previous
From: Aleksander Alekseev
Date:
Subject: Re: [PATCH] dynahash: add memory allocation failure check
Next
From: "David E. Wheeler"
Date:
Subject: Re: extension_control_path and "directory"