Peter Eisentraut <peter_e@gmx.net> writes:
> But shouldn't it more ideally be
> currval: SELECT
> nextval: SELECT + UPDATE
> setval: UPDATE
> because nextval allows you to infer the content of the sequence? (Cf.
> UPDATE tab1 SET a = b requires SELECT + UPDATE on tab1.)
One objection is that testing for both privs will require two aclcheck
calls (since aclcheck(SELECT|UPDATE) will check for the OR not the AND
of the privileges). Not sure it's worth the overhead.
Given that nextval() is really the only interesting operation on
sequences (you cannot do a real UPDATE), I don't see a problem with
interpreting "UPDATE" as "the right to do nextval()" for sequences.
Since currval only returns to you the result of your own prior nextval,
there is no real point in giving it a different privilege bit.
Accordingly I think it *should* be testing UPDATE --- the docs are right
and the code is wrong. (If it weren't for your recent addition of
setuid functions, I'd question why currval bothers to make a privilege
test at all.)
"SELECT" still means what it says: the ability to do a select from
the sequence, which lets you see the sequence parameters. So what
we really have is:
SELECT: read sequence as a tableUPDATE: all sequence-specific operations.
You could maybe make an argument that setval() should have a different
privilege than nextval(), but otherwise this seems sufficient to me.
There is now room in ACL to invent a couple of sequence-specific
privilege bits if it bothers you to use "UPDATE" for the can-invoke-
sequence-functions privilege, but I'm not sure it's worth creating
a compatibility issue just to do that.
regards, tom lane
