ALTERing MV refresh options

[ggevay]

We probably won't implement this in the short term, because it's tough for various reasons:

We'd need to change the running round-up operator. Alternatively, we could just completely recreate the dataflow.

The MV collection's write frontier might regress. One way to get around this would be to just say that the new refresh schedule takes effect only after the next originally planned refresh, but this would prevent such usage of this feature where an already-sealed MV is unsealed and also prevent using the mechanism for REFRESH ON DEMAND. Another solution would be to entirely recreate the collection (and all dependant collections). Another solution would be to not immediately move the write frontier to the next refresh, but keep moving it second by second.

7/9/2024: Subsequent discussion noted that altering existing objects is extremely hard in dataflow land, so the correct solution here might be drop/create.

[ggevay]

Adding the "D-good first issue" label was a misclick? The description says "it's tough for various reasons". (It's in the "Much Later" section of the tracking issue.)

[bosconi]

As discussed, yes, this is not a good first or second issue. Icebox. Brr.