Re: Extension Templates S03E11

On 1 August 2013 18:01, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr> wrote:

> Hi,
>
> Please find attached to this email the latest and greatest version of
> in-line SQL only extensions support, known as "Extension Templates" and
> which could be renamed "In-Catalog Extension Templates".
>
> I've included a high-level description of the patch in a style that
> targets the detailed commit messages for features of that source code
> impact level.
>
> The attached patch is known to address all points raised in the previous
> reviews and to implement the best design we could come up with, thanks
> to immense helping from Tom, Heikki and Markus. Of course, bugs are all
> my precious.
>
> I'm going to register that patch to the next commitfest. It's not the
> only patch I intend to register for september though, as I want to get
> to a usable situation with Event Triggers, so you can expect a series of
> patches for that, covering what couldn't make it previously.
>
> As I think this WIP is about as ready-for-committer as it will ever be,
> it would be fantastic if we could do a single committer review before
> CF2013-09 so that I know that it's going to be accepted… or not. Well at
> least it's in the queue already, we'll see what can be done.
>
> Regards,
>
> ---
> Implement in-catalog Extension Template facility.
>
> Previously, the only way to CREATE EXTENSION involved installing file
> system templates in a place generally owned by root: creation scripts,
> upgrade scripts, main control file and auxilliary control files. This
> patch implements a way to upload all those resources into the catalogs,
> so that a PostgreSQL connection is all you need to make an extension
> available.
>
> By design and for security concerns the current Extension Template
> facility is not able to deal with extensions that need to load a DSO
> module into the backend. Using any other PL is supported though.
>
> An extension created from a template depends on it, and the templates
> are part of any backup script taken with pg_dump. So that at pg_restore
> time, when CREATE EXTENSION is executed the templates are already in
> place.
>
> To be able to do that, though, we need a difference in behavior in
> between the classic file system level templates and the catalog
> templates: there's no dependency tracking happening at all with file
> system templates and those can be changed at will even if an extension
> has been already instanciated from the templates, or even removed.
>
> Apart from the dependency tracking, the only other difference between
> file system templates and catalog templates for extensions is that the
> later are managed per-database. The file system level templates being
> managed per major version of PostgreSQL is considered a drawback of that
> method and not to be immitated by the in-catalog system, more flexible
> by design.
>
> At CREATE EXTENSION time, the file system templates are always prefered
> to the catalog templates. Also, it's prohibited to make available an
> extension in the catalogs if an extension of the same name is already
> available from file system templates. That said, some "race conditions"
> make it still possible to have the same extension name available as a
> file system template and a catalog template. Even if only the former
> will ever get installed, it's been deemed prudent to restrict the
> in-catalog templates for extensions to superusers only.
>

Could you please resubmit this without using SnapshotNow as it's no longer
supported?

Thanks

Thom