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-25 17:57:47 |
Message-ID: | BANLkTi=nvoEtXbLJ63kF__2=4zLL1H_nhw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Leonardo Francalanci | 2011-04-25 18:00:28 | Re: Unlogged tables, persistent kind |
Previous Message | Tom Lane | 2011-04-25 17:57:24 | Re: Unfriendly handling of pg_hba SSL options with SSL off |