On Mon, Apr 25, 2011 at 1:45 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers