Re: Foreign table permissions and cloning

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Hmm, it appears we had some pre-existing inconsistency here, because
> ALL TABLES IN <schema> currently includes views. That's weird, but
> it'll be even more weird if we adopt the approach suggested by this
> patch, which creates ALL FOREIGN TABLES IN <schema> but allows ALL
> TABLES IN <schema> to go on including views. Maybe there is an
> argument for having ALL {TABLES|VIEWS|FOREIGN TABLES} IN <schema> - or
> maybe there isn't - but having two out of the three of them doesn't do
> anything for me.

Yeah, that's a fair point. Another issue is that eventually foreign
tables will probably have some update capability, so designing GRANT
on the assumption that only SELECT should be allowed is a mistake.
In fact, I'd argue that GRANT ought not be enforcing such an assumption
even today, especially if it leads to asymmetry there. Let somebody
GRANT UPDATE if they want to --- there's no need to throw an error until
the update operation is actually tried.

> Putting that together with the comments already made upthread, the
> only behavior changes I think we should make here are:

> - Add GRANT privilege [(column_list)] ON FOREIGN TABLE table TO role.
> - Require that the argument to GRANT privilege [(column_list)] ON
> TABLE TO role be an ordinary table, not a foreign table.

I think this might be going in the wrong direction given the above
thoughts. At the very least you're going to have to make sure the
prohibition is easily reversible.

regards, tom lane