+1 on option 2. I asked for a dev mailing thread because this is a behavior change. I'd suggest more people review this to avoid any surprises.
Thanks Alex for the ideas! I'd postpone the renaming and new feature flags to avoid additional behavior changes. Yufei On Mon, Aug 24, 2026 at 6:46 AM Alexandre Dutra <[email protected]> wrote: > 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 >
