Re: extension_control_path

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>, Sergey Muraviov <sergey(dot)k(dot)muraviov(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: extension_control_path
Date: 2014-02-25 22:07:44
Message-ID: 530D1430.3090402@gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I'm massively in favor of this feature. (I had started writing it about
three times myself.)

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.

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.

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.

Now a few technical problems.

When an extension is not found, I get the error message

ERROR: could not open extension control file "(null)": Bad address

Something is broken there.

In the documentation, order extension_control_path after
dynamic_library_path.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2014-02-25 22:21:57 Re: jsonb and nested hstore
Previous Message Josh Berkus 2014-02-25 22:03:32 Re: jsonb and nested hstore