Re: Extension Templates S03E11

Jeff Davis <pgsql(at)j-davis(dot)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