[postgis-devel] In-place upgrade to 2.0

Paul Ramsey pramsey at opengeo.org
Tue May 24 13:05:06 PDT 2011


I DID NOT KNOW THAT!
That's really excellent, and boy I wish I knew what file I should be
reading to know all these new features... what file should I be
reading?
I'll look at this and see if it's useful for our problem.
P.

On Tue, May 24, 2011 at 12:04 PM, Paragon Corporation <lr at pcorp.us> wrote:
> Yes you are correct -- it will bulk.  You have to drop the views currently
> if you change any column used in a view.  The ability for a view to
> automagically rebuild themselves has been on the plate for as far back as I
> can remember and I don't think its funded yet and it drives Leo crazy :).
>
> However for 9.1 users, 9.1 supports ALTER TYPE  so you could just change the
> TYPE underneath the hood so even if uses use views, it should work to just
> ALTER the TYPE.  But of course you probably already new that :)
>
> Thanks,
> Regina
>
> -----Original Message-----
> From: postgis-devel-bounces at postgis.refractions.net
> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paul
> Ramsey
> Sent: Tuesday, May 24, 2011 11:30 AM
> To: PostGIS Development Discussion
> Subject: Re: [postgis-devel] In-place upgrade to 2.0
>
> 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.
>
> 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
>>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>
> _______________________________________________
> 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