On Wed, Apr 20, 2011 at 11:08 AM, Robert Haas <robertmh...@gmail.com> wrote:
> On Wed, Apr 20, 2011 at 9:59 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Shigeru Hanada <han...@metrosystems.co.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
