Overview
In Oxla, ownership defines the relationship where objects such as databases, tables and schemas belong to a specific role. Keep the following principles in mind regarding ownership:- Indexes do not have explicit owners; the owner of the table also owns its indexes
- Ownership is required to
DROPan object - For grants validation, the owner implicitly has all privileges on the resource:
- For table:
SELECT,INSERT,UPDATE,DELETE - For schema:
USAGE,CREATE
- For table:
Checking Ownership
To check ownerships in Oxla, a superuser can execute the following query:id: role IDdatabase: database nameschema: schema name (empty ifobject_typeis DATABASE)object_name: object name (empty ifobject_typeis SCHEMA or DATABASE)object_type: type of the object
Changing Ownership
To change ownership, use the following syntax:OBJECT_NAME: name of the object, whose ownership they want to changeROLE_NAME: name of the role that will become the new owner of the specified object, or keyword CURRENT_ROLE/CURRENT_USER
Ownership vs Role Privileges
Unlike PostgreSQL, Oxla treats ownership and grants as independent. While owners implicitly have all privileges on their resources, these privileges:- Are not visible in
oxla_internal.oxla_role_ns_grantsoroxla_internal.oxla_role_table_grants - Cannot be revoked
GRANT or REVOKE operations can still be performed on object owner - they will result in creating or removing entries
in oxla_internal.oxla_role_..._grants tables, which are independent of data stored in oxla_internal.oxla_object_owner.
These grants do not matter anything as long as the user is the owner of a given resource,
but they will take effect when the owner is changed.
Examples
Here are a few examples that demonstrate the behaviours described above, assuming there is atable1 and user1 role with USAGE grant in public schema:
-
After the following operations
user1will no longer be the owner oftable1, but will haveSELECTgrant on that table. -
After the following operations
user1will still be able toSELECTfromtable1because of ownership, howeverREVOKEdoes not change anything. -
After the following operations
user1will not have access totable1, however the owner has been changed and grant has been revoked.