Re: Foreign table permissions and cloning - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Foreign table permissions and cloning
Date
Msg-id 17471.1303754570@sss.pgh.pa.us
Whole thread Raw
In response to Re: Foreign table permissions and cloning  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Foreign table permissions and cloning  (Robert Haas <robertmhaas@gmail.com>)
Re: Foreign table permissions and cloning  (Greg Stark <gsstark@mit.edu>)
List 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 by date:

Previous
From: Leonardo Francalanci
Date:
Subject: Re: Unlogged tables, persistent kind
Next
From: Peter Eisentraut
Date:
Subject: Re: Unfriendly handling of pg_hba SSL options with SSL off