[postgis-devel] In-place upgrade to 2.0

[Paul Ramsey]

Well, it was only going to be a temporary thing...
In its place I'm now considering a one-time-only function we could run
that would naively read 'geometry' assuming it is serialized_form and
spit it back out as gserialized. So an in-place upgrade script could
go (a) is this a 1.5 database? (b) ok, find all the tables (c) run
this function on them (d) upgrade the rest of the functions.
The only limitation that approach places is that the in/out functions
and anything else bound to the actual CREATE TYPE statement would have
to remain the same from 1.5 to 2.0. So no renaming those particular C
functions.

P.

On Tue, May 31, 2011 at 2:12 AM, Mark Cave-Ayland
<mark.cave-ayland at siriusit.co.uk> wrote:
> On 24/05/11 16:30, Paul Ramsey wrote:
>
>> 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.
>>
>> P.
>
> GEOMETRY2? That sounds very Oracle-esque... ;)
>
>
> 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
>