Karsten Hilbert writes:
> Am Tue, Mar 25, 2025 at 06:55:34PM -0400 schrieb Tom Lane:
>> Works fine if you don't mess with the view's security_invoker
>> status.
> I know but doing so was kind of the point.
[ shrug... ] It's not going to work. When the view is inlined into
the calling query, you
Am Wed, Mar 26, 2025 at 04:36:55PM -0400 schrieb Tom Lane:
> It is intentional that this happens even if the reference to
> private_col is subsequently optimized away. To do otherwise
> would make implementation artifacts in the optimizer far too
> visible, and there's also a very strong case tha
Am Wed, Mar 26, 2025 at 06:24:14PM +0100 schrieb Karsten Hilbert:
> > Works fine if you don't mess with the view's security_invoker
> > status.
>
> I know but doing so was kind of the point.
>
> The views are created by a "database owner" role having
> access to all tables. Therefore, roles using
Am Tue, Mar 25, 2025 at 06:55:34PM -0400 schrieb Tom Lane:
> Karsten Hilbert writes:
> > I expected this:
>
> > set role "restricted-role";
> > -- this works:
> > select public_col from t_partially_private;
> > -- this fails: with "permission denied on table t_partially_private"
>
Karsten Hilbert writes:
> I expected this:
> set role "restricted-role";
> -- this works:
> select public_col from t_partially_private;
> -- this fails: with "permission denied on table t_partially_private"
> select public_col from v_partially_private;
> to work but
Dear all,
given this schema and role:
create table t_partially_private (
public_col text,
private_col text
);
insert into t_partially_private (public_col, private_col) values
('public value', 'private value');
create view v_partia
