Re: Extensions versus pg_upgrade - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Extensions versus pg_upgrade
Date
Msg-id m24o8ep7sl.fsf@2ndQuadrant.fr
Whole thread Raw
In response to Re: Extensions versus pg_upgrade  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Extensions versus pg_upgrade  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.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


pgsql-hackers by date:

Previous
From: Dan Ports
Date:
Subject: Re: SSI patch version 14
Next
From: Stephen Frost
Date:
Subject: Re: updated patch for foreach stmt