[postgis-devel] Small boo boo

[strk]

On Mon, Aug 24, 2009 at 05:57:22AM -0400, Paragon Corporation wrote:

> My proposal is to go back to when postgis_full_version() had real meaning
> about when you really needed to upgrade your scripts or not.

This was my initial idea, but with Paul we decided to keep it simple
and always require running the upgrade script. It's a simpler procedure
and doesn't put more work on version maintainance.

> So new model
> 
> Do I need to upgrade
> Minor to minor upgrade -- since we change the .so and .dll you always need
> to do a soft upgrade.  You can't actually tell anymore with the
> postgis_full_version() since it will read the old version unless you remove
> the old in which case it will just break.

In the minor to minor case the SQL would still point to the old .dll
You can still tell you didn't upgrade as postgis_full_version will report
the old version and you're expecting the new...

> SELECT postgis_full_version();
> 
> says you need to upgrade then you need to run the upgrade script

In order for postgis_full_version() to tell if you need to upgrade
in this scenario, it'll need to query a postgis_script_installed()
and postgis_scripts_released(). IIRC we did have two such functions,
one in SQL and one from the .dll, for exactly this purpose. I can't
remember if we kept them or reverted when we choosed to keep the
two versions in sync.

> Major  e. 1.3, 1.4,1.5 -> 2.0 you need to do a hard upgrade.
> 
> Does that work for everyone?  In most cases I would expect
> postgis_full_version() going from micro to micro not require a soft upgrade,
> but this would allow us to do that if we need to.

I really don't see how big of a problem running the soft upgrade is,
except when it doesn't work out-of-the-box (which is the case when a new
type is added, or something that can't be create-or-replaced).


--strk;

 Free GIS & Flash consultant/developer      ()  ASCII Ribbon Campaign
 http://foo.keybit.net/~strk/services.html  /\  Keep it simple!