Re: extension_control_path

* Peter Eisentraut (peter_e(at)gmx(dot)net) wrote:
> I'm massively in favor of this feature. (I had started writing it about
> three times myself.)

Agreed.

> The problem I see, however, is that most extensions, by recommendation,
> set module_pathname = '$libdir/pgfoo', and so relocating the control
> files will still end up pointing to a not relocated library file.

I was wondering how that was dealt with- I simply have not had time to
get to looking at this in more detail. I thought the answer I got from
Dimitri was that $libdir would actually end up being resolved to any of
the available directories due to his other patch...? Perhaps we just
need to add in to that list the alternate directory for the control
files? Or, what I had been thinking at one point, was making $libdir
actually be "where this control file lives" instead. There's risk there
though, I suppose, as today only one thing means $libdir.

Another thought that I had was dealing with possible overlaps and
clarifying things, perhaps such as having a mapping of 'name' to
'directory' which remaps $libdir for that 'name' and then extensions
would be created using the 'name' space.

eg:

set module_paths = 'mymodulepath:/path/to/whatever;nextmodulepath:/other';
CREATE EXTENSION mymodulepath:my_extension;

> We would need to remove that and then ask users to keep their
> dynamic_library_path in sync with extension_control_path. That's error
> prone, of course.

I'm starting to regret that dynamic_library_path exists, tbh. Still, I
don't think it'd be too bad to automatically add to that path (or to
what's searched) the module_paths.

> In order to address this properly, we need a new directory structure
> that keeps library files and control files together, similar to how
> Python, Ruby, etc. install things, and then just one path for everything.

Right, that's more-or-less what I was thinking module_path would be.

> Now a few technical problems.

Agree with all these.

Thanks,

Stephen