On 1 August 2013 18:01, Dimitri Fontaine <dimi...@2ndquadrant.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
