Re: Foreign table permissions and cloning

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Shigeru Hanada <hanada(at)metrosystems(dot)co(dot)jp>, Thom Brown <thom(at)linux(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Foreign table permissions and cloning
Date: 2011-04-20 15:08:55
Message-ID: BANLkTi=t-4wHCpjyW8+w_2s1Wm_AgskyfQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-04-20 15:15:06 Re: time-delayed standbys
Previous Message Robert Haas 2011-04-20 15:05:43 Re: time-delayed standbys