[postgis-users] [postgis-devel] Allowing use of PostGIS EXTENSION w/out raster

Regina Obe lr at pcorp.us
Mon Oct 9 01:26:36 PDT 2017

> Could you elaborate on this ? It looks to me that:

>  - How do users migrate to postgis that doesn't have raster ?
 >  proposal 1: ALTER EXTENSION postgis UPDATE TO '<x>noraster'
 >   proposal 2: DROP EXTENSION postgis_raster

> I think proposals are crossed here  

>> The proposals are:
>>  1) Move raster to its own extension "postgis_raster"
>>     See https://trac.osgeo.org/postgis/ticket/3888
>>  2) Provide two versions of extension "postgis"
>>     See https://trac.osgeo.org/postgis/ticket/3890

I think we reversed them
Should be

Proposal 1: DROP EXTENSION postgis_raster;

Proposal 2: ALTER EXTENSION postgis UPDATE TO '<x>noraster';

> Given the above, user needs to know the value of <x> with proposal 1 while
it doesn't with proposal 2. Or did you mean upon upgrade ?

Proposal 2: If you are migrating to a version that wasn't even compiled with
raster support and you came from one that did, all you have to do is

ALTER EXTENSION postgis UPDATE;   and your raster type and functions would
be dropped because the postgis.control file would have default being

And would run scripts necessary to take you to where you are to where you
want to go 2.4.0--2.5.0noraster

So it's only users who insist on having no raster, but want to compile with
raster support that have to know the version they are installing.
So yes they would have to do:

ALTER EXTENSION postgis UPDATE "2.5.0noraster";

Given the OCDness of those people, they probably already know what versions
they have installed of everything and memorized.  
So typing a few characters more is still a big step up from having to
install scripts manually.
If they want to jail their users who they think don't need raster, they can
edit the postgis.control and not inconvenience everyone else (except their
own users) happily using postgis.

--- a side note here

If we don't want those extra scripts, then in order to migrate from say
2.4.0 to 2.5.0noraster, you would have to first upgrade to 2.5.0, but the
extension machinery takes care of that for you assuming you have raster
support installed.

Let's suppose we don't provide a 2.4.0--2.5.0noraster script, then you will
need a postgis installed with raster support  to one without, but if we do
provide said script, you wouldn't need
Raster installed to drop it.

Here's why - if the only chain matching is 

Then the shortest path to go from what you have 2.4.0--2.5.0noraster the
extension machinery would determine it needs to run

Postgis-2.4.0--2.5.0.sql  (which would fail and actually not be available if
you didn't install with raster support)

If we insert a:

Then it would use that since it's a shorter path than going thru

>> I am against option (1) because as it stands it breaks 
>> backward-compatibility in a huge way, both in upgrading your database 
>> and having different instructions for enabling raster support in your 
>> database.

> I agree proposal 1 is not backward compatible in terms what you get under
the "postgis" extension name.

> As for instructions I don't think it's a big deal, there are already
instructions to create multiple extensions (topology):

Other people have written instructions too for raster training.  And now you
expect them to update them 

If you are running postgis < 2.4.0 do 


-- If you are running postgis >= 2.5.0  guess what we made your life a
little harder, don't you love this new feature :)

And having to run all those is freaking annoying.  Why do you want to
inconvenience people by doing more work
And having to remember to update every single one whenever you upgrade.

If PostgreSQL had an 


That updates every dependent extension, I wouldn't be so annoyed by your
proposal.  So go work on that feature please and lets talk after you do

> and enabling raster is already a separate step for non-extension
> install:
> http://postgis.net/docs/manual-2.4/postgis_installation.html#create_new_db

> --strk;

Your point.  Said people that insist on not using extension machinery are 
Have 2 traits in common

1) They are usually developers 
2) They generally don't trust anybody to compile stuff for them.  

Having to run 2 scripts was crap. I hated every moment of it.

Most users just want to start using postgis right away, they don't care that
we gave them $10 bucks instead of $5
Yeah more toys to play with.

They don't say
"Excuse me I only asked for $5 why are you giving me $10?  I want you to
take $5 back."


More information about the postgis-users mailing list