Re: Extension Templates S03E11 - Mailing list pgsql-hackers
From | Dimitri Fontaine |
---|---|
Subject | Re: Extension Templates S03E11 |
Date | |
Msg-id | m2vbz9wm5x.fsf@2ndQuadrant.fr Whole thread Raw |
In response to | Re: Extension Templates S03E11 (Jeff Davis <pgsql@j-davis.com>) |
List | pgsql-hackers |
Jeff Davis <pgsql@j-davis.com> writes: > 1. During the initial development of extensions, there was discussion > about ordered version numbers and dependencies on the version (e.g. > requires foo >= 2.1). Outside the scope of this patch, of course, but is > that something that we can still do later? Or are we building > infrastructure that will make that nearly impossible in a release or > two? The best answer I can think of as of today has been proposed on list already in a patch names "finer extension dependencies", where I failed miserably to explain my ideas correctly to -hackers. Here are the archive links to the opening of the thread and the latest known version of the patch: http://www.postgresql.org/message-id/m2hb0y2bh3.fsf@hi-media.com http://www.postgresql.org/message-id/871uoa4dal.fsf@hi-media-techno.com Meanwhile, at pgcon 2013 unconference about pg_upgrade, with Bruce and Peter we had a chat about this problem, coming from a different parallel that might allow for a better explaning of what is it all about: Distribution binary packages nowadays are tracking symbol level dependencies in between binaries (shared objects and programs).To do so they use some dynamic capabilities (objdump and the like, IIUC). In the PostgreSQL we just can't do that automatically, mainly because of EXECUTE support in PL functions and DO blocks. We are not even able to track inter-function dependencies because of that, so that you're allowed to DROP a function that you actually depend on. The “features” proposal where an extension “provides” a set of at least one feature (its own name) is a way for the extension author to list a subset of the symbols provided in his extension so that other extensions are able to depend on some of them. Then this set of “features” can be edited from a version to the next, adding new “features” and removing existing ones. With “feature” dependency tracking, we are able to prevent extension updates when the new version deprecates features that we know are still in the dependency graph: # ALTER EXTENSION foo UPDATE TO '2.0' ERROR: extension bar depends on feature "baz" provided by "foo" version '1.1' My plan is to be able to someday explain what I was trying to do in a way that allows for the patch to be considered again, and I have some faith in that plan because I remember Peter suddenly understanding what this was all about when in Ottawa earlier this year. It should be quite trivial to update the patch I had then to also support Extension Templates, basically adding a new column in the catalogs, grammar support in the control properties, and making sure that the value actually goes from the template into the extension catalogs at CREATE or UPDATE time. Mind you, if the Extension Templates patch fate is solvable this Commit Fest, and provided that the “extension features” appears to be a good idea for someone else than just me, I would happily be proposing an updated version of it for next Commit Fest, in time fro 9.4. It was a very simple patch. Of course, given Extension Templates, I would be adding some regression tests to said patch ;-) > 2. People will want to start using this feature to control and version > their schema. Do you have comments about that? Should we eventually try > to get extensions to support that use case (if they don't already), or > should that be a completely different feature? The tension between extensions and database schema is pretty simple: an Extension content is not part of pg_dump. With the idea of Extension Templates, you now have two kinds of templates: file system based templates, excluded from the dumps and managed separately (typically managed as an OS package), and catalog templates, parts of the dumps, fully managed by PostgreSQL. Both ways, at pg_restore time the extension is built again from the templates, wherever we find those. The term “extension” covers for a single set of behaviours. So my current thinking is that Extension Templates as currently developped will not be a solution to version controling your database schema. I have not been thinking about how to make that happen other than the following two points: - yes I would like PostgreSQL to offer database versioning capabilities; - no I don't think Extensions can be made into providing support for that set of features. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
pgsql-hackers by date: