Skip to main content
pgschema operates at the schema level. This means it does not support SQL commands that operate the non-schema level objects.

​
Cluster Level Commands

  • CREATE DATABASE
  • CREATE ROLE
  • CREATE TABLESPACE
  • CREATE USER
Roles stay out of your schema files, but you can still grant to them: plan stubs every role your schema references (GRANT/REVOKE, CREATE POLICY ... TO, ALTER DEFAULT PRIVILEGES FOR ROLE) in its temporary database, provided the role exists on the target database. See Roles.

​
Database Level Commands

  • CREATE CAST
  • CREATE COLLATION
  • CREATE CONVERSION
  • CREATE EVENT TRIGGER
  • CREATE EXTENSION
  • CREATE FOREIGN DATA WRAPPER
  • CREATE LANGUAGE
  • CREATE OPERATOR
  • CREATE PUBLICATION
  • CREATE SCHEMA
  • CREATE SERVER
  • CREATE SUBSCRIPTION
  • CREATE TEXT SEARCH
  • CREATE USER MAPPING

​
Schema Level Commands

We plan to support most schema-level commands in the future. Please check other sections for the schema-level database objects that we support right now.

​
Object Ownership

pgschema does not manage which role owns an object. Like pg_dump --no-owner, dump never emits ALTER ... OWNER TO, and plan does not compare owners, so the same schema file stays portable across environments where owners differ. This applies to every OWNER TO form on schema-level objects:
  • ALTER TABLE ... OWNER TO / ALTER FOREIGN TABLE ... OWNER TO
  • ALTER INDEX ... OWNER TO
  • ALTER VIEW ... OWNER TO / ALTER MATERIALIZED VIEW ... OWNER TO
  • ALTER FUNCTION ... OWNER TO / ALTER PROCEDURE ... OWNER TO
  • ALTER AGGREGATE ... OWNER TO
  • ALTER SEQUENCE ... OWNER TO
  • ALTER TYPE ... OWNER TO / ALTER DOMAIN ... OWNER TO
An OWNER TO statement in your schema files has no effect on the plan. plan and apply print a warning for it and skip it, and the owner on the target database stays as it is. When OWNER TO shares an ALTER TABLE with other actions, only the OWNER TO action is skipped.
Objects created by apply are owned by the role that runs it. To get a specific owner, run apply as that role, or change the owner outside of pgschema:

​
Global Default Privileges

ALTER DEFAULT PRIVILEGES is supported only with IN SCHEMA. See ALTER DEFAULT PRIVILEGES. Without IN SCHEMA, the statement sets a default for every schema in the database where the role creates objects. That is database-level state, not part of the schema pgschema manages, and several schemas managed separately would each claim it.
A global ALTER DEFAULT PRIVILEGES statement in your schema files has no effect on the plan. plan and apply print a warning for it and skip it, and the target database is not changed.
Apply global default privileges outside of pgschema, or scope them to the schema:

​
Rename

RENAME is not supported.