Corey,
* Corey Huinker (corey.huinker@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