Robert Haas writes:
> Never mind all this. I think what I have in mind requires doing what
> you did first. So if you're happy with what you've got, I'd go for it.
OK. HEAD-only sounds like a good compromise. Barring objections,
I'll do that later today.
regards, tom la
Robert Haas writes:
> On Mon, May 6, 2024 at 7:31 PM Tom Lane wrote:
>> 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.
If you leave the (I
On Tue, May 7, 2024 at 9:47 AM Robert Haas wrote:
> 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
On Mon, May 6, 2024 at 7:31 PM Tom Lane 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 lea
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 tha
