Re: Foreign table permissions and cloning

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Foreign table permissions and cloning
Дата
Msg-id 17471.1303754570@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Foreign table permissions and cloning  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Foreign table permissions and cloning  (Robert Haas <robertmhaas@gmail.com>)
Re: Foreign table permissions and cloning  (Greg Stark <gsstark@mit.edu>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Apr 25, 2011 at 1:45 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.

Yeah, the existing precedent (not only for GRANT but for some other
things like ALTER TABLE) is that a command that says "TABLE" is allowed
to apply to other relation types if it makes sense to apply it.  It's
only when you name some other object type that we get picky about the
relkind matching exactly.  This is probably more historical than
anything else, but it's the precedent and we shouldn't make foreign
tables be the only thing not following the precedent.

> So now I think this is just a documentation bug.

If the code already works like that for foreign tables, then no
behavioral change is needed.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Leonardo Francalanci
Дата:
Сообщение: Re: Unlogged tables, persistent kind
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Unfriendly handling of pg_hba SSL options with SSL off