Dear Tom,
> I looked at this more carefully. In both SQL92 and SQL99, the only
> Access Rule for GRANT is
>
> 1) The applicable privileges shall include a privilege identifying
> O.
>
> Here "O" is the target object, and "applicable privileges" is all the
> privileges held by the current user.
>
> Now, that says "a privilege", not "the privilege to be granted", nor
> even "a privilege with grant option".
Ok. "identified" privilege seems to be defined in *Syntax* rule 4 and it
includes "with grant option" (section 12.2 <grant privilege statement>).
> As near as I can tell, what the spec wants is that GRANT should raise
> error if the issuing user has no privileges at all for the target
> object, but as long as he has at least one privilege bit, he gets past
> the Access Rule --- whether or not that bit has anything to do with the
> privilege bits to be granted.
Ok, I understand it finally. If it is *empty*, then it is an error, but if
it is not empty, then it proceeds with grantable privileges and warns
about ungrantable ones. What you say above.
> AFAICS the specification for REVOKE is exactly parallel.
Ok, but "identified" means there "those that are currently granted
by A" (12.7 <revoke statement> 9 case a).
> So the existing code is still wrong, but not in quite the way we thought.
Sorry. I sometimes tend to read what I expect instead of what is written
when reading a specs...
> I'd be the first to say that this aspect of the spec is a tad bizarre.
Well, we agree on that;-)
> Does anyone want to argue for ignoring the spec and implementing "saner"
> behavior? It's not like we are super close to spec compliance for
> privileges otherwise ...
I think that if pg really sticks to the spec as I finally understand it
with your help, it would not be bad. I mean with both error (empty set in
grant or revoke) and warnings (non grantable parts for grant, non granted
parts for revoke).
Thanks for your help,
--
Fabien Coelho - coelho@cri.ensmp.fr