Re: ExecutorCheckPerms() hook

* KaiGai Kohei (kaigai@ak.jp.nec.com) wrote:
> We can find out a similar case in CreateTrigger().
> If I was granted TRIGGER privilege on a certain table, I can create a new
> trigger on the table without its ownership. More commonly, it allows us
> to modify a certain property of the table without its ownership.

TRIGGER is hardly the same as REFERENCES.  If we invented a new priv, it
would be more like 'FK_CREATE'.

> Perhaps, if SQL permission would be more fine-grained, for example,
> "RENAME" permission might control RENAME TO statement, rather than
> its ownership.

This wouldn't actually be any more fine-grained, it'd just be adding
rights on to an existing priv, which I think is a wholly *bad* idea.

> What is the reason why we check its ownership here, although we already
> have REFERENCES permission to control ADD FOREIGN KEY?

REFERENCES is needed on the REFERENCED table, ownership is needed on the
REFERENCING table.  They're not the same..

We only allow owners of objects to change the structure of those
objects.  Adding a FK to another table doesn't really change the
structure of the referenced table.  Adding a FK does though, imv.
Thanks,
	Stephen