Re: Extensions support for pg_dump, patch v27

Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com> writes:
> Hi, the attached is a further cleanup of the latest commit
> (1db20cdd36cb1c2cc5ef2210a23b3c09f5058690).

Thanks! Given that the patch contains some merging from master's
branch, I'm not sure if I should apply it to my repository then handle
conflicts, or let you manage the patch now?

> * Accept paths under $PGSHARE during CREATE EXTENSION
> "in addition to" normal paths in convert_and_check_filename().
> I think we don't have to disallow normal file accesses in the case.
> * Rewrite pg_available_extensions() to use materialize mode.
> * Add a protection for nested CREATE EXTENSION calls.
> * Removed some unneeded changes in the patch:
> - utils/genfile.h (use DIR directly)
> - missing merges from master in guc.c
> - only #include changes in a few files
>
> Comments and documentation would need to be checked native
> English speakers. I cannot help you In this area, sorry.

Thanks. I don't see the PATH modifications when reading the patch, though.

> There are last two issues before it goes to ready for committer.
>
> On Mon, Jan 31, 2011 at 19:21, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr> wrote:
>>> * "relocatable" and "schema" seems to be duplicated options.
>> They are not, really.
>
> I'd suggest to remove "relocatable" option if you won't add
> additional meanings to the "relocatable but having schema" case.

The schema option only makes sense when the extension is *NOT*
relocatable.

> Or, I'm still not sure why only adminpack is not relocatable.
> Is it possible to make all extensions to relocatable and add
> "default_schema = pg_catalog" to adminpack for backward-compatibility?

The adminpack SQL script is hard-coding pg_catalog, so user won't be
able to choose where to install it. Technically, they could still move
the functions to another schema, but that would break pgAdmin AFAIUI, so
the extension's author here *wants* to forbid the user to relocate the
extension. And want to prevent to user from installing it where he
wants in the first place.

The option relocatable is allowing ALTER EXTENSION … SET SCHEMA, when
the control files also specify the schema, then you can't choose where
to install the extension in the first place.

I don't think we can go to only 1 options here.

> From older mails:
>>> * Should we support absolute control file paths?
>> Well I don't see no harm in allowing non-core compliant extension
>> packaging,
>
> If you want to support absolute paths, you also need to adjust
> convert_and_check_filename() because it only allows to read files
> in $PGSHARE. So, absolute path support doesn't work actually.
> I prefer to remove absolute path support from script option
> because absolute paths are just unportable.

I have no strong opinion here, ok for me.

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