Re: Review: extension template

From: Markus Wanner <markus(at)bluegap(dot)ch>
To: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
Cc: Hannu Krosing <hannu(at)krosing(dot)net>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Review: extension template
Date: 2013-07-08 09:39:05
Message-ID: 51DA88B9.5070502@bluegap.ch
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 07/08/2013 10:20 AM, Dimitri Fontaine wrote:
> Bypassing the file system entirely in order to install an extension. As
> soon as I figure out how to, including C-coded extensions.

Do I understand correctly that you want to keep the extensions (or their
templates) out of the dump and require the user to "upload" it via libpq
prior to the restor; instead of him having to install them via .deb or .rpm?

This would explain why you keep the CREATE TEMPLATE FOR EXTENSION as a
separate step from CREATE EXTENSION. And why you, too, insist on wanting
templates, and not just a way to create an extension via libpq.

However, why don't you follow the template model more closely? Why
should the user be unable to create a template, if there already exists
an extension of the same name? That's an unneeded and disturbing
limitation, IMO.

My wish: Please drop the pg_depend link between template and extension
and make the templates shared across databases. So I also have to
install the template only once per cluster. Keep calling them templates,
then. (However, mind that file-system extension templates are templates
as well. In-line vs. out-of-line templates, if you want.)

I think you could then safely allow an upgrade of an extension that has
been created from an out-of-line template by an upgrade script that
lives in-line. And vice-versa. Just as an example. It all gets nicer and
cleaner, if the in-line thing better matches the out-of-line one, IMO.

An extension should look and behave exactly the same, independent of
what kind of template it has been created from. And as we obviously
cannot add a pg_depend link to a file on the file system, we better
don't do that for the in-line variant, either, to maintain the symmetry.

> The main feature of the extensions system is its ability to have a clean
> pg_restore process even when you use some extensions. That has been the
> only goal of the whole feature development.

Great! Very much appreciated.

> Let me stress that the most important value in that behavior is to be
> able to pg_restore using a newer version of the extension, the one that
> works with the target major version. When upgrading from 9.2 to 9.3 if
> you depend on keywords that now are reserved you need to install the
> newer version of the extension at pg_restore time.
>
> The main features I'm interested into beside a clean pg_restore are
> UPDATE scripts for extensions and dependency management, even if that
> still needs improvements. Those improvements will be relevant for both
> ways to make extensions available for your system.

+1

> We can not use the name "module" for anything else, IMNSHO.

Agreed.

> The main goal here is not to have the extension live inside the database
> but rather to be able to bypass using the server's filesystem in order
> to be able to CREATE EXTENSION foo; and then to still have pg_restore do
> the right thing on its own.

Note that with the current, out-of-line approach, the *extension*
already lives inside the database. It's just the *template*, that
doesn't. (Modulo DSO, but the patch doesn't handle those either, yet. So
we're still kind of excluding those.)

Allowing for templates to live inside the database as well is a good
thing, IMO.

> If you want to scratch the new catalogs part, then just say that it's
> expected to be really complex to pg_restore a database using extensions,
> back to exactly how it was before 9.1: create the new database, create
> the extensions your dump depends on in that new database, now pg_restore
> your backup manually filtering away the extensions' objects or ignoring
> the errors when pg_restore tries to duplicate functions you already
> installed in the previous step. No fun.

Definitely not. Nobody wants to go back there. (And as Heikki pointed
out, if you absolutely want to, you can even punish yourself that way.)

Regards

Markus Wanner

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2013-07-08 09:49:51 Re: Review: extension template
Previous Message Heikki Linnakangas 2013-07-08 09:23:06 Re: XLogInsert scaling, revisited