Re: Foreign table permissions and cloning

On Wed, Apr 20, 2011 at 11:08 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Apr 20, 2011 at 9:59 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Shigeru Hanada <hanada(at)metrosystems(dot)co(dot)jp> writes:
>>> Attached patch implements along specifications below.  It also includes
>>> documents and regression tests.  Some of regression tests might be
>>> redundant and removable.
>>
>>> 1) "GRANT privilege [(column_list)] ON [TABLE] TO role" also work for
>>> foreign tables as well as regular tables, if specified privilege was
>>> SELECT.  This might seem little inconsistent but I feel natural to use
>>> this syntax for SELECT-able objects.  Anyway, such usage can be disabled
>>> with trivial fix.
>>
>> It seems really seriously inconsistent to do that at the same time that
>> you make other forms of GRANT treat foreign tables as a separate class
>> of object.  I think if they're going to be a separate class of object,
>> they should be separate, full stop.  Making them just mostly separate
>> will confuse people no end.
>
> I agree.

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

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.

That looks like enough to make foreign table handling consistent with
what we're already doing.

Barring objections, I'll go make that happen.

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