Aggregates created in same minor are missed

[robe]

We have an issue that if an aggregate is changed or created in same minor, it will not be recreated or created.

E.g. If you create an aggregate in 2.2.0 and upgrade to 2.2.0devnext you may not get the new aggregate.

While this is an issue mostly for interim dev upgrades, I think it may be an issue too for general micro upgrades — e.g. 2.1.0 to 2.1.3.

Although it is our policy to not change the APIs between micros (and to avoid introducing new functions except where necessary), technically since changing the underlying functions used to support an aggregate don't change the api of aggregate this should be allowed.

[strk]

I think we should still forbid changing underlying functions used to support aggregates in minors, as well as parameter names for functions. That's specifically to allow for the smoothest possible update, and DROP/CREATE aggregate as well as DROP/CREATE function is not a smooth experience (may fail when the function or aggregate is a dependency of any existing object)

That said, I think we should solve this problem for the development builds

[strk]

Note that the only way to change an aggregate definition is to drop it and re-create it, and this is not possible IFF the aggregate is used by a user view, making a soft upgrade impossible. For this very reason it should be highly discouraged to change an aggregate definition in a micro (as you're talking about _micro_, not _minor_) upgrades.

That said, the whole upgrade machinery only uses two version (major and minor) to determine whether something was added so it is hard-coded that nothing changes in a micro. Do we really want to change that ? Do you have a real example of when such change happened in a micro ?

[robe]

strk it's only been an issue with I think raster upgrade — I think we did break the aggregate rule in a micro. The only other time is in doing development upgrades where this is an issue.

I don't forsee us needing to change an aggregate in a micro release.

[strk]

So does it make sense to fix in 2.2.0 ? Sounds like something that should be fixed in 2.1.x in order to allow proper upgrade ? Or should we tag that aggregate as being "changed" in 2.2.0 ? It might help to have a link to the ticket with the actual upgrade issue

[robe]

I can't remember off hand. It might have even been a 2.0 issue where this came about that dustymugs had to change a raster aggregate. The API did not change but functions used had to be changed so had to be dropped recreated. I think he had it as part of the drop create logic separate from your upgrade script.

Anyway I would say lets not bother with 2.1 and just focus on 2.2. It's really only an issue in minor/major development that we are adding / changing aggregates (and we as developers of PostGIS/ would want to be doing a constant upgrade of not yet released minor/major).

[strk]

Also, the summary of this ticket talks about "missing" aggregate, not "changed". I guess it's easier for "missing" ones than it is for "changed" ones as there's no DROP involved. In any case, we're not going to change this in 2.2.0, right ?

[robe]

Yah lets not change

[robe]

I think this was fixed a while ago.