Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
>> - Bugs to fix
>>
>> There's at least one where drop extension leaves things behind,
>> although it uses performDeletion(). The dependencies are fine enough
>> so that the leftover objects are not part of the dump done before to
>> drop, though.
>
> That well seems to me to be an existing bug that I'm just putting in the
> light. The reading of comments from findDependentObjects() makes me
> think that following nested DEPENDENCY_INTERNAL levels is broken, but I
> didn't have time to figure out how exactly, nor to try to fix.
>
> http://git.postgresql.org/gitweb?p=postgresql-extension.git;a=shortlog;h=refs/heads/extension
Here's another version of the patch, v3. Changes:
- mentioned bug is fixed, that indeed was a shortcoming in following
dependencies, due to a new way of using DEPENDENCY_INTERNAL in the
extension code.
- system view pg_extensions, using a function of the same name, lists
all available and installed extensions. That should make the life of
pgAdmin developers easier, among other users :)
- pg_dump now issues CREATE EXTENSION foo WITH NO DATA; variant, and
extension install script can use pg_extension_with_user_data() which
returns true only when they have to create user data objects (often,
fact table with pre-loaded data that the user is free to change)
- pgxs.mk now will use given $(EXTENSION), $(EXTVERSION) and
$(EXTCOMMENT) variables to produce the control file, or use an
existing one. When $(EXTENSION) is not given, it will try to guess it
from $(DATA) and $(DATA_built).
- more documentation, I think it's all covered now
- merges of the cfparser and pg_execute_from_file latest versions, so
that the patch is self-contained and you can test it should you want
to. I intend to merge from the official branch (pgmaster here) then
produce another version of the patch without that code once it's
separately committed, as that's the outlined plan so far.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support