Corey, * Corey Huinker (corey.huin...@gmail.com) wrote: > Craig's post yesterday about exposing syntax for disabling indexes reminded > me of another feature I think we're lacking in areas where we have to do > table management. > > The issue is to create a *something* that has the exact permissions of > another *something*. Usually it's creating a table related to (but not yet > inheriting) a parent, but it could also be to drop and recreate a > *something*, making sure it has the same permissions it had before.
Agreed, that seems like a very sensible use-case. > BEGIN; > > CREATE VIEW dummy AS SELECT 1::text as dummy; > > UPDATE pg_class > SET relacl = ( SELECT relacl FROM pg_class > WHERE oid = 'foo'::regclass) > WHERE oid = 'dummy'::regclass; Yikes, let's not suggest folks go updating catalog tables, ever, please. :) > So it'd be nice to: > ALTER TABLE bar SET PERMISSIONS FROM foo; > or maybe even > GRANT SAME PERMISSIONS ON VIEW bar FROM foo; > > Thoughts? I like the general idea and suspect many others would also, but there's two big questions: Should we have a way for users to define an ACL ala the ALTER DEFAULT PERMISSIONS approach where the ACL is not attached to any particular object and is, instead, something which can be assigned to a table. Further, if we support that, what happens if that is changed later? I could see use-cases for both having that change impact all objects and for not having that happen. Second, as always, what's the syntax going to actually be? I don't think GRANT SAME PERMISSIONS is going to work out too well in the parser, and it seems a bit grotty to me anyway. I do think this should be associated with GRANT rather than ALTER TABLE- GRANT is what we use for managing privileges on an object. Thanks! Stephen
Description: Digital signature