On Mon, May 6, 2024 at 7:31 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert pointed out [1] that the planner fails if we have $SUBJECT, > because tidpath.c can seize on the RLS-derived ctid constraint > instead of the CurrentOfExpr. Since the executor can only handle > CurrentOfExpr in a TidScan's tidquals, that leads to a confusing > runtime error. > > Here's a patch for that. > > However ... along the way to testing it, I found that you can only > get such an RLS qual to work if it accepts "(InvalidBlockNumber,0)", > because that's what the ctid field will look like in a > not-yet-stored-to-disk tuple. That's sufficiently weird, and so > unduly in bed with undocumented implementation details, that I can't > imagine anyone is actually using such an RLS condition or ever will. > So maybe this is not really worth fixing. Thoughts?
Hmm, I thought the RLS condition needed to accept the old and new TIDs, but not (InvalidBlockNumber,0). I might well have misunderstood, though. As to whether this is worth fixing, I think it is, but it might not be worth back-patching the fix. Also, I'd really like to get disable_cost out of the picture here. That would require more code reorganization than you've done here, but I think it would be worthwhile. I suppose that could also be done as a separate patch, but I wonder if that doesn't just amount to changing approximately the same code twice. Or maybe it doesn't, and this is worth doing on its own. I'm not sure; I haven't coded what I have in mind yet. -- Robert Haas EDB: http://www.enterprisedb.com