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
Date: Fri, 05 Jan 2024 10:14:17 -0500
Message-ID: <946635.1704467657@sss.pgh.pa.us> (raw)
In-Reply-To: <18271-70059a372db705e3@postgresql.org>
References: <18271-70059a372db705e3@postgresql.org>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, vost_800@gmx.de, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18271: Re: Postgres policy exists bug
In-Reply-To: <946635.1704467657@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox