Views on DPG — Declarative PG

Regular Views

Mon, 01 Jan 0001 00:00:00 +0000

The AS query clause is Part 1, terminated with ;. An optional { } block holds grants, comments, and the owner.

Basic view

SCHEMA public {
 VIEW active_users AS
 SELECT id, email, created_at
 FROM users
 WHERE status = 'active' AND deleted_at IS NULL;
}

-- emits
CREATE OR REPLACE VIEW "public"."active_users" AS
 SELECT id, email, created_at
 FROM users
 WHERE status = 'active' AND deleted_at IS NULL;

View with explicit column aliases

VIEW user_summary (user_id, email, order_count) AS
 SELECT u.id, u.email, COUNT(o.id)
 FROM users u
 LEFT JOIN orders o ON o.user_id = u.id
 GROUP BY u.id, u.email;

CREATE OR REPLACE VIEW "public"."user_summary" ("user_id", "email", "order_count") AS
 SELECT u.id, u.email, COUNT(o.id)
 FROM users u
 LEFT JOIN orders o ON o.user_id = u.id
 GROUP BY u.id, u.email;

View with `security_barrier`

VIEW secure_user_view WITH (security_barrier = true) AS
 SELECT id, email FROM users WHERE tenant_id = current_tenant();

CREATE VIEW "public"."secure_user_view" WITH (security_barrier=true) AS SELECT id, email FROM users WHERE tenant_id = current_tenant();

security_invoker works the same way. An option written without a value, such as WITH (security_barrier), means true.

Materialized Views

Mon, 01 Jan 0001 00:00:00 +0000

Basic materialized view

SCHEMA analytics {
 MATERIALIZED VIEW daily_revenue AS
 SELECT
 date_trunc('day', created_at) AS day,
 SUM(total_amount) AS revenue,
 COUNT(*) AS order_count
 FROM orders
 WHERE status = 'completed'
 GROUP BY 1;
}

-- emits
CREATE MATERIALIZED VIEW "analytics"."daily_revenue" AS
 SELECT
 date_trunc('day', created_at) AS day,
 SUM(total_amount) AS revenue,
 COUNT(*) AS order_count
 FROM orders
 WHERE status = 'completed'
 GROUP BY 1;

With storage options and `WITH NO DATA`

MATERIALIZED VIEW product_stats
WITH (fillfactor = 90)
TABLESPACE analytics_space AS
 SELECT product_id, COUNT(*) AS purchases, AVG(price) AS avg_price
 FROM order_items
 GROUP BY product_id
WITH NO DATA {
 INDEXES { idx_product_stats_id (product_id); }
 GRANTS { SELECT TO app_readonly; }
}

-- emits
CREATE MATERIALIZED VIEW "public"."product_stats"
 WITH (fillfactor = 90)
 TABLESPACE "analytics_space" AS
 SELECT product_id, COUNT(*) AS purchases, AVG(price) AS avg_price
 FROM order_items
 GROUP BY product_id
WITH NO DATA;

GRANT SELECT ON "public"."product_stats" TO "app_readonly";

CREATE INDEX IF NOT EXISTS "idx_product_stats_id"
 ON "public"."product_stats" ("product_id");

Diffing behaviour

Any change to a materialized view’s query (beyond whitespace, which is normalized away before comparison) emits DROP MATERIALIZED VIEW then CREATE MATERIALIZED VIEW — always DESTRUCTIVE. Unlike regular views, there is no CREATE OR REPLACE MATERIALIZED VIEW.

Recursive Views

Mon, 01 Jan 0001 00:00:00 +0000

Recursive view

SCHEMA public {
 RECURSIVE VIEW org_tree (id, parent_id, depth, path) AS
 SELECT id, parent_id, 0, ARRAY[id]
 FROM departments WHERE parent_id IS NULL
 UNION ALL
 SELECT d.id, d.parent_id, t.depth + 1, t.path || d.id
 FROM departments d JOIN org_tree t ON d.parent_id = t.id;
}

-- emits
CREATE OR REPLACE RECURSIVE VIEW "public"."org_tree"
 ("id", "parent_id", "depth", "path") AS
 SELECT id, parent_id, 0, ARRAY[id]
 FROM departments WHERE parent_id IS NULL
 UNION ALL
 SELECT d.id, d.parent_id, t.depth + 1, t.path || d.id
 FROM departments d JOIN org_tree t ON d.parent_id = t.id;

Recursive views follow the same diffing rules as regular views: query body changes emit CREATE OR REPLACE; output column list changes emit DROP + CREATE (DESTRUCTIVE).

Views on DPG — Declarative PG

Regular Views

Basic view

View with explicit column aliases

View with security_barrier

Materialized Views

Basic materialized view

With storage options and WITH NO DATA

Diffing behaviour

Recursive Views

Recursive view

View with `security_barrier`

With storage options and `WITH NO DATA`