From: Tom Lane <tgl@sss.pgh.pa.us>
To: vost_800@gmx.de
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18271: Re: Postgres policy exists bug
In-reply-to: <18271-70059a372db705e3@postgresql.org>
References: <18271-70059a372db705e3@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Fri, 05 Jan 2024 14:05:59 +0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <946634.1704467657.1@sss.pgh.pa.us>
Date: Fri, 05 Jan 2024 10:14:17 -0500
Message-ID: <946635.1704467657@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/946635.1704467657%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> After submitting my initial report, I attempted to find a workaround for the
> issue. However, during this process, I discovered the same behavior as with
> the EXISTS operation, specifically when dealing with subqueries.

Neither here nor in the other thread have you provided a
*self-contained* example of what you think is wrong.  I experimented
with a function like your example here and couldn't see anything that
looked wrong to me.

As far as this bit goes:

> FALSE IN (
>     SELECT is_private
>     FROM public.profiles AS p
>     WHERE p.user_id = user_id
> )

you do realize that "user_id" here will be resolved as p.user_id
because that's the most closely nested source of such a column?
So that WHERE clause will not provide any useful filter.

Your function example doesn't have that bug, but your original
policy definition looks like it might.

			regards, tom lane