KaiGai Kohei wrote:
One matter was use permission, but I can agree to integrate
it into select permission as the original design did.
Ok, great.
The other is view. When we use a view in the query, it is extracted
as a subquery and its query tree is fetched from pg_rewrite.ev_action
which is
Heikki Linnakangas wrote:
KaiGai Kohei wrote:
The other one is it has two kind of reader permissions (select and
use).
The select permission is applied when user tries to read tables/columns
and its contents are returned to the user.
The use permission is applied when user tries to read
KaiGai Kohei wrote:
Heikki, Thanks for your comments.
Heikki Linnakangas wrote:
Ok, I've taken a quick look at this too. My first impression is that
this is actually not a very big patch. Much much smaller than I was
afraid of. It seems that dropping the row-level security and the other
Ok, I've taken a quick look at this too. My first impression is that
this is actually not a very big patch. Much much smaller than I was
afraid of. It seems that dropping the row-level security and the other
change you've already done have helped a great deal.
My first question is, why does
Heikki, Thanks for your comments.
Heikki Linnakangas wrote:
Ok, I've taken a quick look at this too. My first impression is that
this is actually not a very big patch. Much much smaller than I was
afraid of. It seems that dropping the row-level security and the other
change you've already
KaiGai Kohei wrote:
The other one is it has two kind of reader permissions (select and
use).
The select permission is applied when user tries to read tables/columns
and its contents are returned to the user.
The use permission is applied when user tries to read table/columns,
but its contents
The series of SE-PostgreSQL patches for v8.4 were updated:
[1/5] http://sepgsql.googlecode.com/files/sepgsql-core-8.4devel-r1668.patch
[2/5] http://sepgsql.googlecode.com/files/sepgsql-utils-8.4devel-r1668.patch
[3/5] http://sepgsql.googlecode.com/files/sepgsql-policy-8.4devel-r1668.patch
[4/5]
