[postgis-devel] Extension Versions

Paragon Corporation lr at pcorp.us
Mon Jan 9 11:59:58 PST 2012


> OK, looking at this, the Makefile seems to drive of the 
> .control file for versions, mostly (but not entirely), is the 
> control file used in the extension itself 
Yes its required by the extension and installed as part of the extension.

It denotes for example which version of postgis to install if a person does

CREATE EXTENSION postgis

without any version qualification and is also used to populate the
extensions catalog
when someone does a 

SELECT * FROM pg_extensions;

I suppose we can generate it, but it has to be installed as postgis.control/
postgis_topology.control


> Secondly, looking at some entries i the Makefile, I see more 
> version strings, for the minor upgrades... this seems less 
> that lovely, and could be a pain to automate.
> 
> sql/$(EXTENSION)--2.0.0a11--$(EXTVERSION).sql:
> sql_bits/postgis_raster_upgrade_minor.sql
> 	cp $< $@
> 
Yah that's the part that I couldn't find an easy way of automating.  When we
releast it won't be so bad.
The annoying thing about extensions is that you can not denote a file as
take me from versions 1-4  to 5.

So each version requires a separate file of th form:

postgis--v1--v3.sql
postgis--v2--v3.sql
postgis--v3.sql


etc.  In our case since our minor scripts would update all micros its a bit
redundant.

You can however have a 

postgis--v1--v2.sql
postgis--v2--v3.sql
postgis--v3.sql


Which would end up running both scripts to take a user from version 1 to
version 3. So perhaps for our micros releases
we just have a static version of the prior micro we commit at each release
cycle and have the make file only create the next.

> 
> Finally, this entry disturbed me because it is pulling .in 
> and .in.c files into a .sql file, which seems dangerous at 
> best. Why is it doing this/?
> 
> sql_bits/postgis_raster_upgrade_minor.sql:
> ../postgis_extension_helper.sql sql_bits/remove_from_extension.sql.in
> ../../postgis/postgis_drop_before.sql.in.c
> sql_bits/postgis_upgrade_minor.sql
> 	sql_bits/rtpostgis_upgrade_20_minor.sql
> ../../doc/raster_comments.sql  ../../doc/postgis_comments.sql 
> ../postgis_extension_helper_uninstall.sql
> 	cat $^ > $@
> 

The .sql.in.c should just be the postgis_drop_before.sql that is generated.

I'm deliberating on just renaming remove_from_extension.sql.in to
remove_from_extension.sql

What is our convention on what .in files should contain?  I've always
assumed its a fully functional sql that is not
meant to stand on its on.


Thanks,
Regina





More information about the postgis-devel mailing list