Re: WHERE CURRENT OF with RLS quals that are ctid conditions

On Mon, May 6, 2024 at 7:31 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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