Learn about ownership in Firebolt & how it impacts permissions and access control.
When you create an object in Firebolt, you become its owner. As the owner, you have full control and can perform all operations on the object without needing additional privileges. This allows you to use objects immediately after creating them.
As the owner of an object, you can do the following:
Firebolt supports ownership at both the organization level and the account level.
The following organization-level objects support ownership:
Organization-level object owners must be either a login or a service account. You cannot make a user the owner of an organization-level object.
The following account-level objects support ownership:
Account-level object owners must be users. You cannot make a login or service account the owner of an account-level object.
The current owner of an object can be viewed in the corresponding information_schema
view:
Object Type | View |
---|---|
Organization | information_schema.organization |
Account | information_schema.accounts |
Login | information_schema.logins |
Service Account | information_schema.service_accounts |
Network Policy | information_schema.network_policies |
Role | information_schema.enabled_roles |
Location | information_schema.locations |
User | information_schema.users |
Database | information_schema.catalogs |
Engine | information_schema.engines |
Schema | information_schema.schemata |
Table | information_schema.tables |
View | information_schema.views or information_schema.tables |
Indexes inherit ownership from their parent table. In information_schema.indexes
, the table owner is displayed as the index owner.
You can transfer ownership of an object using the following syntax:
Note that the identity type must match the level of the object:
The following examples demonstrate how to change the ownership of different object types.
Before dropping a user who owns objects, you must either drop the objects owned by the owner or transfer ownership of them to another user.
The following code example shows how to drop a table that has dependent views not owned by the table’s owner using the CASCADE
parameter to enforce the drop: