Hi Ayush, Thanks for raising this issue.
I think that option 2 is cleaner, and I'd also advocate to rename DROP_WITH_PURGE_ENABLED to PURGE_TABLE_METADATA_ON_DROP for clarity. That said, if there is concern about narrowing down the scope of DROP_WITH_PURGE_ENABLED, I could also see a 3rd option: - Introduce a new PURGE_TABLE_METADATA_ON_DROP flag (default false). - To purge a table, require PURGE_TABLE_METADATA_ON_DROP + DROP_WITH_PURGE_ENABLED - To purge a view, require PURGE_VIEW_METADATA_ON_DROP + DROP_WITH_PURGE_ENABLED In this option, DROP_WITH_PURGE_ENABLED becomes a higher-level flag that stops all purges at once, while the other two flags gate the feature for tables or views only. Thanks, Alex On Mon, Aug 24, 2026 at 3:06 PM Jean-Baptiste Onofré <[email protected]> wrote: > > Hi Ayush > > That's a known issue, and I consider as a bug. For context, it's a > conflict defaults problem: DROP_WITH_PURGE_ENABLED=true (the guard) > plus PURGE_VIEW_METADATA_ON_DROP=true (the default behavior) means > views cannot be dropped at all out of the box (a 403 is thrown because > the drop internally requests purge=true but the purge guard blocks > it). > > I think option 2 is the best approach for a "real" long-term fix: > DROP_WITH_PURGE_ENABLED was almost designed as a safety guard for > table storage. Views don't have the same destructive storage > implications, so conflating them under one flag is a category error > imho. Scoping to tables only and letting PURGE_VIEW_METADATA_ON_DROP > stand on its own makes the intent of each flag unambiguous. > > I'm in favor of implementing #2 "quickly". > > Regards > JB > > On Sun, Aug 23, 2026 at 12:29 PM Ayush Saxena <[email protected]> wrote: > > > > Hi All, > > Following the discussion in [1] and [2], which deal with the problem that > > views cannot be dropped under default configurations, > > > > *The problem* > > ----------- > > Two feature flags interact here: > > > > *DROP_WITH_PURGE_ENABLED* default: false > > *PURGE_VIEW_METADATA_ON_DROP* default: true > > > > Dropping a view internally passes purge=true whenever > > PURGE_VIEW_METADATA_ON_DROP is enabled, and that request then hits the > > DROP_WITH_PURGE_ENABLED guard in the shared drop path. With the defaults > > above, the two contradict each other and every view drop fails with 403 > > Forbidden, even though the caller never asked for a purge. > > > > So out of the box, views cannot be dropped at all. Operators have to > > discover and flip one of the two flags to get a working view lifecycle. > > > > *Possible solutions* > > ------------------ > > 1. Change the default of PURGE_VIEW_METADATA_ON_DROP to false. The > > current changes in PR [2] > > > > Views become droppable out of the box and the two defaults stop > > contradicting each other. The trade-off is that purging view metadata > > would then require both flags to be enabled, which keeps the two flags > > coupled like it is today preserving the current behaviour. > > > > 2. Narrow DROP_WITH_PURGE_ENABLED to tables only. > > > > The guard would no longer apply to views, leaving > > PURGE_VIEW_METADATA_ON_DROP as the single, independent control for view > > metadata purging. This decouples the two settings, at the cost of > > changing what > > DROP_WITH_PURGE_ENABLED covers today. There is also an existing > > integration test asserting the current coupled behaviour, linked in > > the issue [1] > > > > 3. Maybe something else or some combination of the two, for example > > narrowing the scope and also > > revisiting the default. > > > > Let me know what folks think about this!!! > > > > -Ayush > > > > [1] https://github.com/apache/polaris/issues/5293 > > [2] https://github.com/apache/polaris/pull/5322
