[raster] raster Upgrade script doesn't work because of new type

[robe]

I see someone created a bandmetadata type. Can we get rid of it? and instead use out parameters. The band metadata function that uses it already has OUT parameters so actually may cause a problem if those get out of synch. Though maybe this isn't possible since the first is exposed via a C function.

I also don't see the point of having the C function use a variadic int. Why can't it just atake an array of band numbers so it's consistent with ST_Band?

As a general rule, we should avoid creating types unless they are used a lot or are complex objects such as raster.

The problem with types is that they are difficult to upgrade since PostgreSQL has no CREATE IF NOT EXISTS yet for types and even then it would be impossilbe to change them. We could create functions to check the system catalogs and create them if they don't exist etc, but that gets messy.

[Bborie Park]

OK. I've removed the type in r8295.

[robe]

Same issue with geomvalxy. I'll take care of this one Bborie since I see you have your hands full :)

[Bborie Park]

Oh. The only reason ST_Band isn't variadic while ST_BandMetadata is is that when I wrote ST_Band, we were still supporting PGSQL 8.3. Don't tempt me to go make ST_Band variadic ;-)

I like the uber-flexibility that variadic parameters permit...

ST_BandMetadata(rast, 1, 2, 3, 4, 5)

or

ST_BandMetadata(rast, VARIADIC ARRAY[1,2,3,4,5])

[robe]

I don't for the plain reason that I can't do

array_agg(number_field) or ARRAY[].. which is important when you are dealing with a rast that you don't necessarily know the number of bands you will need before hand.

which I can with arrays

Granted it's not as simple as writing 1,2,3, but with variadic for this kind of thing, I loose one level of flexibility.

[robe]

oh forgot about the ARRAY(SELECT num from ...) option. That you loose too with making this variadic.

[Bborie Park]

Valid arguments. OK. I've removed the variadic from ST_BandMetadata.

[Bborie Park]

Variadic removed in r8300

[robe]

okay got rid of use of geomvalxy and purged it though still need to add that st_pixelaspolygons or whatever to regress to make sure I didn't break it.

Sadly there is a more difficult one to get rid of so upgrade still doesn't work so I may still need to make concessions for adding new types if they don't exist.

The ST_union aggregate function also introduces a new type rastexpr which it uses for a state transition and all over the place. I'm not sure if that can be irradicated. I think anyway the ST_Union needs a closer look which I'll try to take a look at hopefully this weekend or early next week, because its got WAY TOO MANY moving parts and the internal funcs aren't prefixed with _ to denote they are internals.

[robe]

forgot changes I made are at r8302

[robe]

this works for me now cleanly. Though puzzled what kind of issue Chris could be having in #1372 since my upgrade seems to be working cleanly now for both extension upgrade and using the upgrade script.