Re: Extensions, this time with a patch

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Extensions, this time with a patch
Date: 2010-10-18 11:37:43
Message-ID: m24ocjwx2w.fsf@2ndQuadrant.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)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

Attachment Content-Type Size
extension.v3.patch.gz application/octet-stream 35.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2010-10-18 12:48:16 Re: string function - "format" function proposal
Previous Message Itagaki Takahiro 2010-10-18 11:37:24 Re: string function - "format" function proposal