"Jaime Casanova" <[EMAIL PROTECTED]> writes:
> + if (istmt.all_privs)
> + istmt_seq.all_privs = true;
> + else
> + {
> + if (istmt.privileges & ACL_INSERT)
> + istmt_seq.privileges |= ACL_USAGE;
> + if (istmt.privileges & ACL_UPDATE)
> + istmt_seq.privileges |= ACL_UPDATE;
> + if (istmt.privileges & ACL_SELECT)
> + istmt_seq.privileges |= ACL_SELECT;
> + }
This definition of the derived rights seems pretty arbitrary and
unprincipled. If you can't explain it precisely in a few words in the
documentation (and I notice you didn't even attempt to explain it at
all), then you probably need to think harder.
In particular, I don't see why having UPDATE on the parent table should
grant the right to use setval() on the sequence. If you had INSERT and
DELETE as well, implying the right to make arbitrary changes in the
parent table, then maybe setval() would be sensible to allow --- but
this code can't really tell that, since it doesn't have a global view
of the privileges previously granted.
What I think makes sense is just to have parent INSERT privilege lead to
USAGE on the sequence (thus granting nextval/currval rights, which are
what you'd typically need in association with trying to do inserts).
I don't see any need to automatically grant more than that. Selects and
updates on the parent table don't need to touch the sequence, so why are
those privileges granting anything?
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
