[postgis-devel] Small boo boo

[Paragon Corporation]

>> 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.
Given that we won't be changing APIs  from micro to micro, I think your
initial idea makes more sense now.  The only time we should 
need to change the .sql file is for I think about 4 plpgsql functions if we
need to bug fix them.  So the message that you need to upgrade all the time
I find really annoying. But I guess I get more irritated by these things
more than most people do.

> 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..
Yap, but you won't see a proc needs upgrade message is all.

> 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.

I traced the path and as far as I can tell -- all that logic is still in
place so its just that configure.ac that probably needs to be changed.


> 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).
Well I find it annoying mostly because I have a lot of spatial databases on
one server.  So in my case - I know I upgrade each at the same time.  If the
script didn't waste my time by telling me I need to upgrade, then I could
just check one database and say

"Ah they didn't change anything" and be done with it and not risk messing
something else up like my custom search path settings. 

Besides I kind of like it as a meta-documenting feature to know the last
time we changed the scripts in a micro version.
Again for micro to micro I expect .sql changing to be very rare now where as
before it was very common since we were allowed to add functions in a micro
version.

Thanks,
Regina