Re: Extensions versus pg_upgrade

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Extensions versus pg_upgrade
Date: 2011-02-08 20:53:30
Message-ID: m24o8ep7sl.fsf@2ndQuadrant.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Personally I find the extension stuff to be a bigger deal than anything
> else remaining in the commitfest. Also, I've fixed a number of
> pre-existing bugs in passing, and I'd have to go extract those changes
> out of the current extensions patch if we abandon it now. So I'd like
> to keep pushing ahead on this.

Stealing words from Kevin, WOO-HOO :) I'll try to continue devote as
much time as I did already to assist as much as I can here.

> After further reflection I think that the pg_upgrade situation can be
> handled like this:
>
> 1. Provide a way for CREATE EXTENSION to not run the script --- either
> add a grammar option for that, or just have a back-door flag that
> pg_upgrade can set via one of its special kluge functions. (Hm,
> actually we'd want it to install the old version number and comment
> too, so maybe just have a kluge function to create a pg_extension
> entry that agrees with the old entry.)

In the upgrade patch there's provision for not running the script:

CREATE WRAPPER EXTENSION foo;

That's pretty useful indeed. What it does now is read the control file
to init the comment and other fields, but extversion is forced NULL.
That allows to have special rules in how UPGRADE will pick a script.

There's even code to do

CREATE WRAPPER EXTENSION foo WITH SYSID 12345;

We could add version and comment here for purposes of pg_upgrade.

> 2. Invent a command "ALTER EXTENSION extname ADD object-description"
> that simply adds a pg_depend entry marking an existing object as
> belonging to the extension. I think this was going to be part of the
> plan anyway for ALTER EXTENSION UPGRADE, specifically we need that for
> the bootstrap case of collecting some loose pre-existing objects into
> an extension.

In the upgrade patch, that's spelled ALTER OBJECT foo SET EXTENSION bar;
and does exactly what you're proposing.

> 3. In --binary-upgrade mode, pg_dump doesn't suppress the individual
> member objects, but instead emits ALTER EXTENSION ADD after creating
> each member object.
>
> So that gets us to the point of being able to run pg_upgrade without
> changing the contents of the extension. After that we can look at
> ALTER EXTENSION UPGRADE.

Well, or begin there as the code you need is already written.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2011-02-08 20:55:53 Re: updated patch for foreach stmt
Previous Message Dan Ports 2011-02-08 20:53:05 Re: SSI patch version 14