On Mon Nov 24, 2025 at 11:14 AM EST, Robert Haas wrote: > On Sat, Nov 22, 2025 at 7:43 PM Dian Fay <[email protected]> wrote: >> Since the policies don't contain any execution boundaries, all the quals >> should be going into a single bucket for planning if I understand the >> process correctly. The bitmap heap scan should be a candidate given the >> `tags &&` predicate (and indeed if I switch to a privileged role, the >> advice matches successfully without any policies in the mix), but gdb >> shows the walker bouncing out of pgpa_walker_contains_scan without any >> candidate scans for the BITMAP_HEAP_SCAN strategy. > > In this particular case, I think the problem is that the user-supplied > qual item.tags @> ARRAY[id] is not leakproof and therefore must be > tested after the security qual. There's no way to use a Bitmap Heap > Scan without reversing the order of those tests.
Right, I keep forgetting the functions underneath those array operators aren't leakproof. Thanks for digging. > And honestly, this is one of the things I'm worried about if we go > forward with this, that we'll get a ton of people who think it doesn't > work because it doesn't force the planner to do things which the > planner rejects on non-cost considerations. We're going to need really > good documentation to explain to people that if you use this to try to > force a plan and you can't, that's not a bug, that's the planner > telling you that that plan shape is not able to be considered for some > reason. Once we're closer to consensus on pg_plan_advice or something like it landing, I'm interested in helping out on this end of things!
