Re: Foreign table permissions and cloning

On Mon, Apr 25, 2011 at 1:45 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.

I'm not sure I quite understood what you were saying there, but I'm
coming around to the view that this is already 100% consistent with
the way views are handled:

rhaas=# create view v as select 1;
CREATE VIEW
rhaas=# grant delete on v to bob;
GRANT
rhaas=# grant delete on table v to bob;
GRANT

If that works for a view, it also ought to work for a foreign table,
which I think is what you were saying.

So now I think this is just a documentation bug.

Do you agree?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company