Notes on default create permissions in PG

- New pg_catalog table:

  pg_namespace_default_acl (names can be changed to protect the innocent)
    relnamespace - OID of the schema
    grantobjtype - Grantable object kind, char(1) similar to relkind but for all
               types of grantable objects; this is already defined in an enum
               in parsenodes.h: GrantObjectType or some such
               'r' - table
               'v' - view
               'f' - function
               'S' - sequence
               'C' - column
               'l' - language
               'W' - foreign-data wrapper
               'F' - foreign server

    def_acls[] - array of acls that the object should have on creation
                 this is NOT a mask, it's exactly what the object will get, in
                 other words, the default PG perms are ignored if this is
                 a def_acl in here for that schema/obj_kind

                 This will look like a regular list of perms, eg:
                 {role1=arwd/sfrost,role2=r/sfrost}

    Full row examples:
    2200, 'r', '{role1=arwd/sfrost,role2=r/sfrost}'
    2200, 'v', '{role1=r/sfrost,role2=r/sfrost}'

- New syntax added to ALTER SCHEMA to support this

  - Note: not using grant/revoke terms (or those commands for that matter)
    because it implies something is actually going to happen for existing
    objects, which isn't true.  This is only for new objects which are
    being created

  - suggestion
  ALTER SCHEMA blah SET DEFAULT ACL TABLE select to role1,role2
                                    TABLE insert to role2
                                    VIEW select to role1;

  - or force types to be done seperately and reorder things:
  - Below is probably better
  ALTER SCHEMA blah SET DEFAULT TABLE ACL select to role1,role2
                                      ACL insert to role2;

  ALTER SCHEMA blah SET DEFAULT VIEW ACL select to role1;

  - Also allow using all for either side (priv list or role list):
  ALTER SCHEMA blah DROP DEFAULT VIEW ACL all from role1;

  ALTER SCHEMA blah DROP DEFAULT TABLE ACL select from all;

  ALTER SCHEMA blah ADD DEFAULT TABLE ACL all TO role1;

  - all for 'ADD' implies public, below mean the same
  ALTER SCHEMA blah ADD DEFAULT TABLE ACL SELECT TO all;
  ALTER SCHEMA blah ADD DEFAULT TABLE ACL SELECT TO public;

  - possible syntax for ownership
    - This will probably be implemented seperately as there is some
      concern about security.  Intent is to implement this as
      essentially a 'ALTER TABLE blah OWNER TO role1;' as the user
      creating the table, so they will need the same perms they
      need to do that to begin with.  This is just a convenience
      mechanism, not a change in what people are allowed to do.
    - should mean that you need to be a member of the role you're
      changing the ownership to, and that role need CREATE rights
      on the schema.
  ALTER SCHEMA blah ADD DEFAULT TABLE OWNER role1;

  - Another suggestion for syntax:
  alter schema blah set default permissions on table ...

  Gotta see how this complicates gram.y, etc.

  - Maybe also support syntax to implement the default ACL for an
    object, this would wholesale replace the existing perms, eg:

  ALTER TABLE blah SET DEFAULT ACL;

  Alternativly, for the arguments above, perhaps have GRANT syntax
  support this general capability, eg:

  GRANT DEFAULT ON TABLE blah;

  Also support ADD/DROP default acl to allow adding to and deleteing from the
  def_acls[] list so you don't always have to specify the entire list.  If
  'set' is used, then everything will be replaced by whatever is provided.