Support for PostgreSQL 9.1+ new Extensions model

[robe]

Since this feature was partly created with us in mind, we should take advantage of it. We might not get to it for PostGIS 2.0 though sicne I haven't looked at how much effort is involved.

So with the new way people would be spatially enabling their PostgreSQL database with

CREATE EXTENSION postgis VERSION '2.0';

This will also result in cleaner backups and restores since from what I can gather there are provisions to not backup functions etc. with data.

This will make a bunch of other things easier. People wanting to install in a postgis schema or migrate their existing to postgis schema.

ALTER EXTENSION postgis SET SCHEMA postgis;

And upgrading will be easier as well so to upgrade from an old 2.0.0 that wasn't packaged as an extension would be in theory as simple as.

CREATE EXTENSION postgis VERSION '2.0' FROM unpackaged;

Still unclear how our minor upgrade would work or if we would have to label our version VERSION '2.0.0' to allow people to upgrade easily.

ALTER EXTENSION postgis UPDATE TO '2.0.1'

[strk]

Do you have a link to a mailing list archive for the "created with us in mind" statement ? It all sounds very exciting

[robe]

​http://archives.postgresql.org/pgsql-hackers/2011-02/msg00950.php ​http://archives.postgresql.org/pgsql-hackers/2011-02/msg01084.php

[robe]

Okay I have committed my work so far on this at r7851

I haven't integrated with the rest of make install, but each can be installed separately.

I have some outstanding issues I noted in the README.

But with this so far I can do this on my 9.1 windows instance:

CREATE EXTENSION postgis_core; CREATE EXTENSION postgis_raster;

The postgis_topology one I'm getting an error which I haven't had a chance to troubleshoot.

I also haven't marked spatial_ref_sys table as being user changeable.

[robe]

As discussed. So are we in agreement of merginging in raster

What should this extension be called?

postgis or maybe postgis-2 or postgis_core.

I was thinking about whether postgis_topology should be merged as well, and that one I think we need to keep separate because it is always installed in the topology schema.

The way postgresl 9.1 extensions work, all the components of an extension need to be installed in the same schema toehrwise it will be confusing aif a user tries to switch the schema and it switches for some part of it and not all of it.

[robe]

okay I have merged postgis and postgis raster into a single extension at r7906. Still need to create an unpackaged routine for postgis similar to what I have for postgis_topology already and also an upgrade path.

[robe]

Okay I think I have this working pretty well now . Only one I don't have is the unpackaged case and also folding it in with the regular make install to install if it detects 9.1.

The fresh install and upgrade from prior sorta alpha seems to work well. Will need some regress tests to confirm.

[strk]

I just tested a "make && make install" and then did the "CREATE EXTENSION" and everything seems to be working. So the install part seems good.

Do we want to use the CREATE EXTENSION model on "make check" too for 9.1 ? Does it make sense to also test the other (old) way in 9.1 ?

[strk]

A —extension switch to run_test should let us do both old and new style regressing. I won't be looking into this before 15 hours so if someone wants to try it go ahead … may be worth moving all the DB preparation into a function.

[robe]

Makes sense to also test old I think because there is no way right now to upgrade 9.1 between non-tagged versions. So for example in theory you can upgrade from alpha2 to alpha5 with extensions but you can't go from an alpha6SVN to another alpha6SVN because there is no unique versioning.

Although would be good to add to our list of testing the extension version piece. I didn't have an old alpha* handy to upgrade last time I did an experimental build release.

[strk]

Alright, with r9243 we have an —extensions switch to run_test. You can try that manually running run_test or specifying it as part of RUNTESTFLAGS, ie: $ make check RUNTESTFLAGS='—extensions -v'

You'll get failures from tickets.sql where having both raster _and_ core in the same spatial db introduces ambiguities. Is this an occasion to disambiguate at the rtpostgis.sql level like we did in other cases or should we update the testcase instead ?

[strk]

Oh, another thing to look at for regress testing is how to tell postgresql where to find extensions…

[strk]

Well, so far it looks like there's _no_way_ to tell postgresql where to find extensions at runtime.

[strk]

See here for discussion about _adding_ the support for runtime extension dir settings: ​http://archives.postgresql.org/pgsql-hackers/2012-02/msg00941.php

My last concern about all of this is the consistency between pre-extension having raster and core separated and post-extension having them togheter. I'd feel much better with a 1:1 mapping between pre and post extensions.

[robe]

I think an unpackaged will solve everything. I'm closing this out.