Re: Foreign table permissions and cloning - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Foreign table permissions and cloning
Date
Msg-id 1303754973.5006.46.camel@vanquo.pezone.net
Whole thread Raw
In response to Re: Foreign table permissions and cloning  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On mån, 2011-04-25 at 13:35 -0400, Robert Haas wrote:
> Hmm, it appears we had some pre-existing inconsistency here, because
> ALL TABLES IN <schema> currently includes views.

Which makes sense because you use GRANT ... ON TABLE to grant privileges
to 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.  For now I think we should go with the path of least
> resistance and just document that ALL TABLES IN <schema> now includes
> not only views but also foreign tables.

Yes.

> 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.

But that would be contrary to the SQL standard.  The current behavior is
fine, AFAICT.




pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Unfriendly handling of pg_hba SSL options with SSL off
Next
From: "Kevin Grittner"
Date:
Subject: Re: Unlogged tables, persistent kind