I've run into an interesting quirk of Phoenix metadata while doing PHOENIX-6186, which adds a "last DDL timestamp" to tables and views showing the last time a table/view was created or had a column added or dropped.
The quirk is the "diverged view" feature. Phoenix supports dropping a column from a view that was originally inherited from a base table or parent view. After that, the view is considered "diverged", which has several effects, only the first of which is documented[1]. 1. The user-dropped column is missing from the diverged view (makes sense) 2. Any column subsequently _added_ to the parent base table or a parent view WILL NOT BE inherited by the child diverged view. (Surprising!) 3. But any column subsequently _dropped_ from the parent base table or parent view WILL be inherited by the child diverged view. (Really, really surprising to me given #2) (Chinmay, please correct me if I got any of the above wrong. :-) ) I don't see how 2 follows from 1, or how 3 follows from 1 and 2. (I could _maybe_ see protecting a diverged view from drops, because that can break queries, but that's not the behavior here.) This would make me less likely to actually use this feature. I'm told this made the splittable system catalog effort harder, and it makes my current work difficult, since a diverged view can't just take the max of it and its ancestors' last DDL timestamps to resolve at read time. I also can't set the right value at DDL time because in a splittable syscat world I can't update the view header row when the base table adds a column because the table and view metadata could be in different regions. So before I have to choose between several not-great options to preserve this diverged view behavior, I thought I'd ask: since it's undocumented, and seems counter-intuitive to me, what do we lose by changing it instead? Are there use cases where this is helpful or that have been built expecting this behavior? Thanks, Geoffrey [1] Limitation 5 in http://phoenix.apache.org/views.html#Limitations
