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
