Re: BUG #18271: Re: Postgres policy exists bug
От | Tom Lane |
---|---|
Тема | Re: BUG #18271: Re: Postgres policy exists bug |
Дата | |
Msg-id | 946635.1704467657@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #18271: Re: Postgres policy exists bug (PG Bug reporting form <noreply@postgresql.org>) |
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: