[postgis-devel] In-place upgrade to 2.0

Paul Ramsey pramsey at opengeo.org
Tue May 24 08:30:12 PDT 2011

yes, my scheme was going to be to two-step by first creating
GEOMETRY2, then altering all the columns to that (by maintaining an
lwgeom handler to do the cast from serialized_form to gserialized),
then creating GEOMETRY and altering all the columns to that. Which
would work fine for data-only databases, but installations with more
complex constructions (views, triggers) expecting 'geometry' input
arguments might balk if I alter their column types underneath them.


On Mon, May 23, 2011 at 1:49 AM, Mark Cave-Ayland
<mark.cave-ayland at siriusit.co.uk> wrote:
> On 21/05/11 10:56, Paul Ramsey wrote:
>> The mechanism is the same for everyone, the 9.1 users just get it
>> "automagically" with a SQL command and everyone else has to (quell
>> horror!) run a .sql file.
>> Though now that I think about it in the clear light of early morning
>> there's lots of ways my scheme will fail, so perhaps not.
> I thought that in-place upgrade only works if the binary formats are
> unchanged? So if we change LWGEOM -> G_GEOMETRY then this isn't going to
> work. Or does the extension upgrade execute an ALTER COLUMN statement to
> rebuild the column anyway?
> ATB,
> Mark.
> --
> Mark Cave-Ayland - Senior Technical Architect
> PostgreSQL - PostGIS
> Sirius Corporation plc - control through freedom
> http://www.siriusit.co.uk
> t: +44 870 608 0063
> Sirius Labs: http://www.siriusit.co.uk/labs
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel

More information about the postgis-devel mailing list