Re: REVIEW: Extensions support for pg_dump

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Anssi Kääriäinen <anssi(dot)kaariainen(at)thl(dot)fi>
Cc: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: REVIEW: Extensions support for pg_dump
Date: 2011-01-18 13:25:26
Message-ID: 878vyiuywp.fsf@hi-media-techno.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Anssi Kääriäinen <anssi(dot)kaariainen(at)thl(dot)fi> writes:

> On 01/18/2011 01:03 PM, Dimitri Fontaine wrote:
>> I'd appreciate a list of yet-to-fix items. What I have is the
>> search_path issue where CREATE EXTENSION foo; can leave it changed for
>> the current session, I intend to fix that later today.

After some reading of backend/catalog/namespace.c and some testing, my
take would be to have extension authors use the following form when that
is necessary:

SET LOCAL search_path TO public;

Now, none of the contribs use that form (they all are relocatable except
for adminpack which forces its objects to get installed in pg_catalog),
so I've only updated the documentation.

> There is only documentation fixes, and I am not sure if even those are
> agreed to be necessary. It might be good if the documentation contained:
>
> - A warning that you need to have the files for your extensions readily
> available to be able to restore from a dump. This might be obvious, but
> better safe than sorry...

Added a § about that in the docs.

> - A warning that you will be restored to the extension's version if you
> ALTER or CREATE OR REPLACE a function.

Well I don't want to encourage people to manually edit any extension
objects directly, so I've added a note about not doing that.

> Other than that, I don't think there is anything more. I am a little nervous
> of restoring to extension's version of a function when the function has been
> CREATE OR REPLACEd, but that might be just me over thinking this. Also, from

Well with the next patch in the series, ALTER EXTENSION UPGRADE, you
will have a way to edit extension's objects and have the new version
installed next time, but there's no magic bullet here, it means work to
do by the extension's author (preparing upgrade scripts and new
version's install-from-scratch scripts).

> the previous posts, there is just the control file naming issue, and the
> issue of load order if two extensions contain similarly named and signatured
> functions. But these were agreed to be issues not needing any further work.

Yes, extension dependencies and conflicts are not meant to be covered yet.

> Now, I need help what to do next. Should I leave the status as Needs Review
> as the pg_dump part is almost completely non-reviewed? And then attach this
> thread as a comment? Or as a review?

My guess would be to leave it as Needs Review and add this thread as a
review.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2011-01-18 13:26:06 Re: pg_basebackup for streaming base backups
Previous Message Magnus Hagander 2011-01-18 13:11:33 Re: pg_basebackup for streaming base backups