Robert Haas <robertmh...@gmail.com> writes:
> This might work for RLS policies, if they can only reference a single
> table, but I can't see how it's going to work for security barrier
> views. For example, consider CREATE VIEW v WITH (security_barrier) AS
> SELECT * FROM x, y WHERE x.a = y.a followed by SELECT * FROM v WHERE
> leak(somefield). somefield is necessarily coming from either x or y,
> and you can't let it be passed to leak() except for rows where the
> join qual has been satisfied.
Right, so quals from above the SB view would have to not be allowed to
drop below the join level (but they could fall *to* the join level,
where they'd be applied after the join's own quals). I mentioned that
in the part of the message you cut. I don't have a detailed design yet
but it seems possible, and I expect it to be a lot simpler than the Rube
Goldberg design we've got for SB views now.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
