Fabien COELHO <[EMAIL PROTECTED]> writes:
> Due to how ACL are defined in SQL, I restate my suggestion that the super
> user should be able to change ANY right, including the GRANTOR field,
I'm unconvinced of this: that philosophy soon leads you into allowing
the superuser to create self-inconsistent sets of rights, such as rights
that flow from "nowhere" (i.e., are not traceable through an unbroken
chain to the original owner's grant options). The changes we have been
making recently are specifically designed to prevent such situations,
and I don't really wish to backtrack.
It's worth pointing out also that the superuser can always brute-force
things:
UPDATE pg_class SET relacl = '{ ... anything ...}' WHERE ...
and so we don't really need to provide escape hatches in GRANT/REVOKE
that are only useful to superusers. I think our concern with
GRANT/REVOKE should be to provide a self-consistent set of operations.
We're about there AFAICT with respect to GRANT/REVOKE themselves, but
ALTER OWNER as currently defined breaks it.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
