Re: extension_control_path - Mailing list pgsql-hackers

Hi,

Peter Eisentraut <peter_e@gmx.net> writes:
> I'm massively in favor of this feature.  (I had started writing it about
> three times myself.)

Thanks!

> 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.

It's kind of true. Is the phrasing “typically” followed by an example
really a recommendation though? I though it was more a detailed
explanation of the way it works.

We still have several other ways to tell PostgreSQL which lib to use for
each and every LANGUAGE C function:
 - $libdir/soname - absolute/path - MODULE_PATHNAME - any/relative/path which is to be solved in dynamic_library_path

Also, editing the AS '$libdir/foo' occurences from an SQL script is a
quite very easy thing to do programmatically.

> 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 don't see any pressure in changing the way things currently work after
adding this new GUC in. As you say, when extension_control_path is used
then some extra work *might need* to be done in order to ensure that the
right library is getting loaded.

I mainly see that as a distribution/distributor problem tho.

> 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.

It might be true, be it reads to me like you're omiting the directory
parameter from the control file: the scripts and auxilliary control
files might be found anywhere else on the file system already.

Again, my view is that if you want to do things in a non-standard way
then you need to tweak the control file and maybe the script files. It's
a distribution problem, and I'm solving it in an extra software layer.

PostgreSQL is very flexible about where to organise extension files
currently, *except* for the control file. This patch is providing the
same level of flexibility to this part. Of course flexibility can be
seen as creating a mess, but I don't think it's this patch nor
PostgreSQL core to solve that mess.

> Now a few technical problems.

Will see about fixing those later, by friday given my current schedule,
thanks.

> Also, the documentation states that this controls the location of the
> control file, but it of course controls the location of the script files
> also.  That should be made clearer.  (It becomes clearer if we just have
> one path for everything. ;-) )

Again, we have directory = 'whatever' in the control file to control
where to find the script files. I'm not sure your "of course" follows.
Will still edit docs.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support