Re: Foreign table permissions and cloning

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Apr 25, 2011 at 1:45 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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