postgis upgrade scripts not outputting geometry_columns

[robe]

The create replace view is entirely missing from the gneerated postgis_upgrade_20_minor.sql.

The upgrade scripts should also drop geometry_columns table if it exists.

[robe]

Okay I give up on this one. Can one of you perl geeks take acare of this. I assume it's jsut the postgis_proc_upgrade.pl that needs to be changed. I tried adding geometry_columns to the top and tried to get rid of the conditional check on version in create or replace view. All that happened is my regress managed to break and was generating a postgis.sql that didn't have the regress postgis.lib (was pointing at my produciton). Not sure how those 2 are connected.

Anyrate:

1) There is no reason WHAT SO EVER I can think of to not run

CREATE OR REPLACE VIEW even on a minor upgrade, because as long as the column names and types don't change, then even dependent objects will be unaffected.

on a minor upgrade

2) Fro a major upgrade we might have to do a drop REPLACE, but lets just assume for simplicity we will never change the outter exterior (types of columns, column names) except possibly to add columns at the end. Adding columns at the end is doable with a CREATE OR REPLACe

so short -- we should always do a CREATE OR REPLACE VIEW for both minor and major

[strk]

Was the proc_upgrade script even meant to be run for major upgrades ?

[strk]

Fixed in r8380. I suspect the major version parts are all broken. At least I remember I did add an function for the sole purpose of bailing out when a major upgrade was attempted.

[robe]

No don't think so but it should work for micro and minor. I ran into issues when upgrading my older PostGIS 2.0 when I revised the guts of the internals. In minor releases we are allowed to change the public interface e.g. adding new columns etc.

In micro we are allowed to change the guts of a view as long as we don't change the exposed interface - e.g we can change how a column is computed as long as the output column has same name,type, size.