From: Tom Lane <tgl@sss.pgh.pa.us>
To: 875941708@qq.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17549: wrong index scan plan with RLS
In-reply-to: <17549-5114159516d34c2d@postgresql.org>
References: <17549-5114159516d34c2d@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Wed, 13 Jul 2022 11:45:54 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2221346.1657722459.1@sss.pgh.pa.us>
Date: Wed, 13 Jul 2022 10:27:39 -0400
Message-ID: <2221347.1657722459@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2221347.1657722459%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> # for RLS user, index scan can only use column a, and filter by lower(b)
> set app.a=1;
> explain analyse select * from abc where a=1 and lower(b)='1234';
>      Index Scan using abc_a_lower_idx on abc
>          Index Cond: (a = 1)
>          Filter: (lower(b) = '1234'::text)

AFAICS this is operating as designed.  It's unsafe to apply the
non-leakproof condition until we've verified that the row has a = 1.

In the particular case shown here, it might be all right to do it,
but cases such as bitmap indexscans or lossy index opclasses could
result in live re-evaluations of the indexqual conditions at some
rows.  So we can't safely allow lower(b) to become part of the
indexquals.

			regards, tom lane