Alastair McKinley <a.mckinley@analyticsengines.com> writes:
> Thank you for having a look at this. In the interim I discovered that I could trigger the issue by creating a
securitybarrier view, whereas a regular view worked fine, so I think that also points to your conclusion about
leakyness?
> I attempted to workaround the issue with a leakproof function, so far with no success.
> ...
> Is this an approach that could fundamentally work?
Forcing the expression to be considered leakproof should work.
I'm not sure that your partial index is OK for the purpose of
collecting stats, though -- does it help if you make a non-partial
index on that function expression? Otherwise, it's possible that
I guessed wrong about which part of the WHERE clause is problematic.
You could try doing EXPLAINs with different portions of the WHERE
to see how the rowcount estimate changes.
BTW, just marking something "leakproof" when it isn't really so
is possibly a security problem. You should think twice about
what threat model you're hoping RLS will protect against.
regards, tom lane