@caoscompanybr/merlin 3.5.0

package/.merlin-core/skills/general/database/references/postgres-concurrency.md

@@ -0,0 +1,182 @@
+# PostgreSQL Concurrency & Locking
+
+Patterns for safe concurrent access: advisory locks, deadlock prevention, transaction discipline, and queue processing with SKIP LOCKED.
+
+## Advisory Locks
+
+Application-level coordination without requiring database rows to lock on. Useful for singleton processes, report generation, and resource coordination.
+
+**Incorrect (creating rows just for locking):**
+
+```sql
+CREATE TABLE resource_locks (resource_name TEXT PRIMARY KEY);
+INSERT INTO resource_locks VALUES ('report_generator');
+SELECT * FROM resource_locks WHERE resource_name = 'report_generator' FOR UPDATE;
+```
+
+**Correct (advisory locks — no table needed):**
+
+```sql
+-- Session-level lock (released on disconnect or explicit unlock)
+SELECT pg_advisory_lock(hashtext('report_generator'));
+-- ... do exclusive work ...
+SELECT pg_advisory_unlock(hashtext('report_generator'));
+
+-- Transaction-level lock (auto-released on COMMIT/ROLLBACK)
+BEGIN;
+SELECT pg_advisory_xact_lock(hashtext('daily_report'));
+-- ... do work ...
+COMMIT;  -- Lock automatically released
+```
+
+Non-blocking try-lock (returns immediately):
+
+```sql
+-- Returns TRUE if acquired, FALSE if already held
+SELECT pg_try_advisory_lock(hashtext('resource_name'));
+-- Application checks result, skips or retries if not acquired
+```
+
+## Deadlock Prevention
+
+Deadlocks occur when transactions lock resources in different orders. Always acquire locks in a **consistent order**.
+
+**Incorrect (inconsistent lock ordering → deadlock):**
+
+```sql
+-- Transaction A                    -- Transaction B
+BEGIN;                              BEGIN;
+UPDATE accounts SET balance =       UPDATE accounts SET balance =
+  balance - 100 WHERE id = 1;        balance - 50 WHERE id = 2;
+-- A locks row 1                    -- B locks row 2
+
+UPDATE accounts SET balance =       UPDATE accounts SET balance =
+  balance + 100 WHERE id = 2;        balance + 50 WHERE id = 1;
+-- A waits for B's lock on row 2   -- B waits for A's lock on row 1
+-- DEADLOCK!
+```
+
+**Correct (acquire all locks in ID order first):**
+
+```sql
+BEGIN;
+-- Lock rows in consistent order BEFORE updating
+SELECT * FROM accounts WHERE id IN (1, 2) ORDER BY id FOR UPDATE;
+
+-- Now update in any order — locks already held
+UPDATE accounts SET balance = balance - 100 WHERE id = 1;
+UPDATE accounts SET balance = balance + 100 WHERE id = 2;
+COMMIT;
+```
+
+Alternative — single statement (acquires all locks atomically):
+
+```sql
+UPDATE accounts
+SET balance = balance + CASE id
+  WHEN 1 THEN -100
+  WHEN 2 THEN  100
+END
+WHERE id IN (1, 2);
+```
+
+Detect deadlocks:
+
+```sql
+-- Check for recent deadlocks
+SELECT datname, deadlocks FROM pg_stat_database WHERE deadlocks > 0;
+
+-- Enable deadlock logging
+SET log_lock_waits = on;
+SET deadlock_timeout = '1s';
+```
+
+## Short Transactions
+
+Long-running transactions hold locks that block other queries. Keep transactions as short as possible — **never do external I/O inside a transaction**.
+
+**Incorrect (external call inside transaction):**
+
+```sql
+BEGIN;
+SELECT * FROM orders WHERE id = 1 FOR UPDATE;  -- Lock acquired
+-- Application makes HTTP call to payment API (2-5 seconds)
+-- ALL other queries touching this row are blocked!
+UPDATE orders SET status = 'paid' WHERE id = 1;
+COMMIT;  -- Lock held for entire duration
+```
+
+**Correct (minimal transaction scope):**
+
+```sql
+-- Do validation and API calls OUTSIDE the transaction
+-- Application: response = await paymentAPI.charge(...)
+
+-- Only hold the lock for the actual database update
+BEGIN;
+UPDATE orders
+SET status = 'paid', payment_id = $1
+WHERE id = $2 AND status = 'pending'
+RETURNING *;
+COMMIT;  -- Lock held for milliseconds
+```
+
+Prevent runaway transactions:
+
+```sql
+-- Abort queries running longer than 30 seconds
+SET statement_timeout = '30s';
+
+-- Per-transaction override
+SET LOCAL statement_timeout = '5s';
+```
+
+## SKIP LOCKED Queue Pattern
+
+When multiple workers process a queue, `SKIP LOCKED` lets each worker grab the next available row without waiting for other workers' locks. **10x throughput** for worker queues.
+
+**Incorrect (workers block each other):**
+
+```sql
+BEGIN;
+SELECT * FROM jobs WHERE status = 'pending'
+ORDER BY created_at LIMIT 1 FOR UPDATE;
+-- Worker 2 waits for Worker 1's lock to release!
+```
+
+**Correct (SKIP LOCKED — parallel processing):**
+
+```sql
+BEGIN;
+SELECT * FROM jobs
+WHERE status = 'pending'
+ORDER BY created_at
+LIMIT 1
+FOR UPDATE SKIP LOCKED;
+-- Worker 1 gets job 1, Worker 2 gets job 2 (no waiting)
+
+UPDATE jobs SET status = 'processing' WHERE id = $1;
+COMMIT;
+```
+
+Atomic claim-and-update (single statement):
+
+```sql
+UPDATE jobs
+SET status = 'processing', worker_id = $1, started_at = now()
+WHERE id = (
+  SELECT id FROM jobs
+  WHERE status = 'pending'
+  ORDER BY created_at
+  LIMIT 1
+  FOR UPDATE SKIP LOCKED
+)
+RETURNING *;
+```
+
+## References
+
+- [Advisory Locks](https://www.postgresql.org/docs/current/explicit-locking.html#ADVISORY-LOCKS)
+- [Deadlocks](https://www.postgresql.org/docs/current/explicit-locking.html#LOCKING-DEADLOCKS)
+- [Transaction Management](https://www.postgresql.org/docs/current/tutorial-transactions.html)
+- [SELECT FOR UPDATE SKIP LOCKED](https://www.postgresql.org/docs/current/sql-select.html#SQL-FOR-UPDATE-SHARE)

package/.merlin-core/skills/general/database/references/postgres-connections.md

@@ -0,0 +1,97 @@
+# PostgreSQL Connection Management
+
+Connection pooling and limit configuration to prevent database crashes and handle high concurrency.
+
+## Connection Pooling
+
+PostgreSQL forks a new process per connection, each consuming 1-3MB RAM. Without pooling, applications exhaust connections under load.
+
+**Without pooling (connection per request):**
+
+```sql
+-- 500 concurrent users = 500 connections = database crash
+SELECT count(*) FROM pg_stat_activity;  -- 487 connections!
+```
+
+**With pooling (shared pool):**
+
+```sql
+-- 500 concurrent users share 10 actual database connections
+-- Connection pooler sits between application and database
+SELECT count(*) FROM pg_stat_activity;  -- 10 connections
+```
+
+### Pool Sizing Formula
+
+```
+pool_size = (CPU cores × 2) + spindle_count
+```
+
+Example for 4 cores with SSD: `(4 × 2) + 1 = 9` connections. Round up to 10.
+
+### Pool Modes
+
+| Mode            | Behavior                                   | Use When                                       |
+| --------------- | ------------------------------------------ | ---------------------------------------------- |
+| **Transaction** | Connection returned after each transaction | Most web apps (stateless requests)             |
+| **Session**     | Connection held for entire client session  | Prepared statements, temp tables, SET commands |
+
+**Transaction mode** is best for most applications — it maximizes connection reuse.
+
+**Session mode** is required when using:
+
+- Prepared statements (`PREPARE`/`EXECUTE`)
+- Temporary tables (`CREATE TEMP TABLE`)
+- Session-level settings (`SET` commands)
+- `LISTEN`/`NOTIFY`
+
+## Connection Limits
+
+Too many connections exhaust memory and degrade performance. Set limits based on available resources.
+
+**Incorrect (excessive connections):**
+
+```sql
+SHOW max_connections;  -- 500 (way too high for 4GB RAM)
+-- Each connection uses 1-3MB RAM
+-- 500 × 2MB = 1GB just for connections!
+```
+
+**Correct (calculate based on resources):**
+
+```sql
+-- Formula: (RAM_MB / 5MB per connection) - reserved
+-- For 4GB: (4096 / 5) - 10 = ~800 theoretical max
+-- Practical recommendation: 100-200 for query performance
+
+ALTER SYSTEM SET max_connections = 100;
+```
+
+### work_mem Budget
+
+```sql
+-- work_mem × max_connections should not exceed 25% of RAM
+-- For 4GB RAM with 100 connections: 1024MB / 100 = 10MB max
+ALTER SYSTEM SET work_mem = '8MB';  -- 8MB × 100 = 800MB (safe)
+```
+
+### Monitor Connection Usage
+
+```sql
+-- Connections by state
+SELECT count(*), state
+FROM pg_stat_activity
+GROUP BY state;
+
+-- Find long-running idle connections
+SELECT pid, now() - state_change AS idle_time, query
+FROM pg_stat_activity
+WHERE state = 'idle'
+ORDER BY idle_time DESC;
+```
+
+## References
+
+- [Connection Settings](https://www.postgresql.org/docs/current/runtime-config-connection.html)
+- [pg_stat_activity](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ACTIVITY-VIEW)
+- [Resource Consumption](https://www.postgresql.org/docs/current/runtime-config-resource.html)

package/.merlin-core/skills/general/database/references/postgres-data-patterns.md

@@ -0,0 +1,159 @@
+# PostgreSQL Data Access Patterns
+
+Efficient patterns for bulk operations, pagination, upserts, and table partitioning.
+
+## Batch Inserts
+
+Individual INSERT statements have high overhead per row. Batch multiple rows or use COPY for bulk loading.
+
+**Incorrect (individual inserts — 1000 round trips):**
+
+```sql
+INSERT INTO events (user_id, action) VALUES (1, 'click');
+INSERT INTO events (user_id, action) VALUES (1, 'view');
+INSERT INTO events (user_id, action) VALUES (2, 'click');
+-- ... 1000 separate statements = 1000 round trips
+```
+
+**Correct (multi-row insert — 1 round trip):**
+
+```sql
+INSERT INTO events (user_id, action) VALUES
+  (1, 'click'),
+  (1, 'view'),
+  (2, 'click'),
+  -- ... up to ~1000 rows per batch
+  (999, 'view');
+```
+
+**Fastest (COPY for bulk loading):**
+
+```sql
+COPY events (user_id, action, created_at)
+FROM '/path/to/data.csv'
+WITH (FORMAT csv, HEADER true);
+```
+
+Impact: **10-50x faster** than individual inserts.
+
+## Cursor Pagination (vs OFFSET)
+
+OFFSET-based pagination scans all skipped rows, getting slower on deeper pages. Cursor/keyset pagination is O(1) regardless of page depth.
+
+**Incorrect (OFFSET — gets slower per page):**
+
+```sql
+-- Page 1: scans 20 rows
+SELECT * FROM products ORDER BY id LIMIT 20 OFFSET 0;
+
+-- Page 100: scans 2000 rows to skip 1980
+SELECT * FROM products ORDER BY id LIMIT 20 OFFSET 1980;
+
+-- Page 10000: scans 200,000 rows!
+SELECT * FROM products ORDER BY id LIMIT 20 OFFSET 199980;
+```
+
+**Correct (keyset — constant speed):**
+
+```sql
+-- Page 1: get first 20
+SELECT * FROM products ORDER BY id LIMIT 20;
+-- Application stores last_id = 20
+
+-- Page 2: start after last ID (uses index, always fast)
+SELECT * FROM products WHERE id > 20 ORDER BY id LIMIT 20;
+
+-- Page 10000: same speed as page 1
+SELECT * FROM products WHERE id > 199980 ORDER BY id LIMIT 20;
+```
+
+Multi-column sorting:
+
+```sql
+-- Cursor includes ALL sort columns
+SELECT * FROM products
+WHERE (created_at, id) > ('2024-01-15 10:00:00', 12345)
+ORDER BY created_at, id
+LIMIT 20;
+```
+
+## Upsert (INSERT ... ON CONFLICT)
+
+Separate SELECT-then-INSERT creates race conditions. Use atomic upsert instead.
+
+**Incorrect (race condition):**
+
+```sql
+-- Two requests check simultaneously, both find nothing, both try to insert
+SELECT * FROM settings WHERE user_id = 123 AND key = 'theme';
+INSERT INTO settings (user_id, key, value) VALUES (123, 'theme', 'dark');
+-- One succeeds, one fails with duplicate key error!
+```
+
+**Correct (atomic upsert):**
+
+```sql
+-- Insert or update in a single atomic operation
+INSERT INTO settings (user_id, key, value)
+VALUES (123, 'theme', 'dark')
+ON CONFLICT (user_id, key)
+DO UPDATE SET value = EXCLUDED.value, updated_at = now()
+RETURNING *;
+```
+
+Insert-or-ignore pattern:
+
+```sql
+INSERT INTO page_views (page_id, user_id)
+VALUES (1, 123)
+ON CONFLICT (page_id, user_id) DO NOTHING;
+```
+
+## Table Partitioning
+
+Partitioning splits a large table into smaller physical pieces. Queries only scan relevant partitions. Maintenance (VACUUM, DROP old data) operates on individual partitions.
+
+**When to partition:**
+
+- Tables > 100M rows
+- Time-series data with date-range queries
+- Need to efficiently drop old data (DROP TABLE is instant vs DELETE taking hours)
+
+**Without partitioning (single large table):**
+
+```sql
+-- 500M rows, queries scan everything
+SELECT * FROM events WHERE created_at > '2024-01-01';  -- Slow
+VACUUM events;  -- Takes hours
+```
+
+**With partitioning (by time range):**
+
+```sql
+CREATE TABLE events (
+  id bigint GENERATED ALWAYS AS IDENTITY,
+  created_at timestamptz NOT NULL,
+  data jsonb
+) PARTITION BY RANGE (created_at);
+
+-- Monthly partitions
+CREATE TABLE events_2024_01 PARTITION OF events
+  FOR VALUES FROM ('2024-01-01') TO ('2024-02-01');
+CREATE TABLE events_2024_02 PARTITION OF events
+  FOR VALUES FROM ('2024-02-01') TO ('2024-03-01');
+
+-- Queries only scan relevant partitions
+SELECT * FROM events WHERE created_at > '2024-01-15';
+-- Only scans events_2024_01 and later
+
+-- Drop old data instantly (no row-by-row DELETE)
+DROP TABLE events_2023_01;
+```
+
+Impact: **5-20x faster** queries and maintenance on large tables.
+
+## References
+
+- [INSERT ON CONFLICT](https://www.postgresql.org/docs/current/sql-insert.html#SQL-ON-CONFLICT)
+- [COPY](https://www.postgresql.org/docs/current/sql-copy.html)
+- [Table Partitioning](https://www.postgresql.org/docs/current/ddl-partitioning.html)

package/.merlin-core/skills/general/database/references/postgres-monitoring.md

@@ -0,0 +1,136 @@
+# PostgreSQL Monitoring & Diagnostics
+
+Deep query analysis, performance tracking, and maintenance tuning beyond the basics in SKILL.md.
+
+## EXPLAIN ANALYZE Deep Dive
+
+`EXPLAIN ANALYZE` executes the query and shows actual timings — the definitive tool for diagnosing slow queries.
+
+```sql
+EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT)
+SELECT * FROM orders WHERE customer_id = 123 AND status = 'pending';
+```
+
+### Red Flag Checklist
+
+Read the output and look for these problems:
+
+| Red Flag                      | What It Means                     | Fix                                                        |
+| ----------------------------- | --------------------------------- | ---------------------------------------------------------- |
+| `Seq Scan` on large table     | Missing index                     | Add index on filtered columns                              |
+| High `Rows Removed by Filter` | Poor selectivity or missing index | Add more specific index or composite index                 |
+| `Buffers: read >> hit`        | Data not cached in memory         | Increase `shared_buffers` or add index to reduce scan      |
+| `Sort Method: external merge` | `work_mem` too low for sort       | Increase `work_mem` or add index matching ORDER BY         |
+| `Nested Loop` with high loops | Potentially slow join             | Check for missing index on join column, consider Hash Join |
+| `Hash Batches > 1`            | Hash table spilled to disk        | Increase `work_mem`                                        |
+
+### Example Output Analysis
+
+```
+Seq Scan on orders  (cost=0.00..25000.00 rows=50 width=100)
+                    (actual time=0.015..450.123 rows=50 loops=1)
+  Filter: ((customer_id = 123) AND (status = 'pending'::text))
+  Rows Removed by Filter: 999950        ← Scanned 1M rows, kept 50
+  Buffers: shared hit=5000 read=15000   ← 15K blocks from disk (slow)
+Planning Time: 0.150 ms
+Execution Time: 450.500 ms              ← Fix: add composite index
+```
+
+After adding index:
+
+```sql
+CREATE INDEX orders_customer_status_idx ON orders (customer_id, status);
+```
+
+```
+Index Scan using orders_customer_status_idx on orders
+  (cost=0.42..8.44 rows=50 width=100)
+  (actual time=0.025..0.089 rows=50 loops=1)
+  Buffers: shared hit=4
+Execution Time: 0.112 ms                ← 4000x faster
+```
+
+## pg_stat_statements
+
+Tracks execution statistics for all queries. Essential for finding the queries consuming the most resources.
+
+```sql
+-- Enable the extension (once)
+CREATE EXTENSION IF NOT EXISTS pg_stat_statements;
+
+-- Top 10 slowest queries by total execution time
+SELECT
+  calls,
+  round(total_exec_time::numeric, 2) AS total_time_ms,
+  round(mean_exec_time::numeric, 2) AS mean_time_ms,
+  query
+FROM pg_stat_statements
+ORDER BY total_exec_time DESC
+LIMIT 10;
+
+-- Most frequent queries (may indicate N+1 patterns)
+SELECT calls, query
+FROM pg_stat_statements
+ORDER BY calls DESC
+LIMIT 10;
+
+-- Queries with high average time (optimization candidates)
+SELECT query, round(mean_exec_time::numeric, 2) AS mean_ms, calls
+FROM pg_stat_statements
+WHERE mean_exec_time > 100  -- Over 100ms average
+ORDER BY mean_exec_time DESC;
+
+-- Reset statistics after optimization round
+SELECT pg_stat_statements_reset();
+```
+
+## VACUUM & ANALYZE
+
+Outdated statistics cause the query planner to make poor decisions. `VACUUM` reclaims dead tuple space. `ANALYZE` updates statistics used by the planner.
+
+### When to Run
+
+```sql
+-- Manually analyze after large data changes (bulk import, migration)
+ANALYZE orders;
+
+-- Analyze specific columns used in WHERE clauses
+ANALYZE orders (status, created_at);
+```
+
+### Check Staleness
+
+```sql
+-- Tables sorted by most stale (never analyzed first)
+SELECT
+  relname,
+  last_vacuum,
+  last_autovacuum,
+  last_analyze,
+  last_autoanalyze,
+  n_dead_tup
+FROM pg_stat_user_tables
+ORDER BY last_analyze NULLS FIRST;
+```
+
+### Autovacuum Tuning for High-Churn Tables
+
+Default autovacuum triggers at 20% dead tuples — too late for busy tables.
+
+```sql
+-- Tune for high-write tables (e.g., events, logs, queue)
+ALTER TABLE events SET (
+  autovacuum_vacuum_scale_factor = 0.05,   -- Vacuum at 5% dead tuples (default 20%)
+  autovacuum_analyze_scale_factor = 0.02   -- Analyze at 2% changes (default 10%)
+);
+
+-- Check autovacuum progress
+SELECT * FROM pg_stat_progress_vacuum;
+```
+
+## References
+
+- [EXPLAIN](https://www.postgresql.org/docs/current/sql-explain.html)
+- [pg_stat_statements](https://www.postgresql.org/docs/current/pgstatstatements.html)
+- [Routine Vacuuming](https://www.postgresql.org/docs/current/routine-vacuuming.html)
+- [Monitoring Statistics](https://www.postgresql.org/docs/current/monitoring-stats.html)

package/.merlin-core/skills/general/database/references/postgres-rls.md

@@ -0,0 +1,140 @@
+# PostgreSQL Row-Level Security (RLS)
+
+Database-enforced access control that ensures users only see their own data, regardless of application bugs or SQL injection.
+
+## RLS Basics
+
+Row Level Security enforces data access at the database level. Even if application code is bypassed, the database itself prevents unauthorized access.
+
+**Without RLS (application-level filtering only):**
+
+```sql
+-- Relies on application to filter — bug or bypass exposes ALL data
+SELECT * FROM orders WHERE user_id = $current_user_id;
+
+-- If application logic is bypassed:
+SELECT * FROM orders;  -- Returns ALL orders for ALL users
+```
+
+**With RLS (database-enforced):**
+
+```sql
+-- Enable RLS on the table
+ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
+
+-- Create policy: users see only their own orders
+CREATE POLICY orders_user_policy ON orders
+  FOR ALL
+  USING (user_id = current_setting('app.current_user_id')::bigint);
+
+-- Force RLS even for table owners (critical for security)
+ALTER TABLE orders FORCE ROW LEVEL SECURITY;
+
+-- Set user context before queries
+SET app.current_user_id = '123';
+SELECT * FROM orders;  -- Only returns orders for user 123
+```
+
+Policy scoped to a specific role:
+
+```sql
+CREATE POLICY orders_user_policy ON orders
+  FOR ALL
+  TO authenticated
+  USING (user_id = current_setting('app.current_user_id')::uuid);
+```
+
+## RLS Performance Optimization
+
+Poorly written RLS policies can cause severe performance issues. The key pattern: **wrap function calls in a subquery** so they execute once, not per-row.
+
+**Incorrect (function called for every row):**
+
+```sql
+CREATE POLICY orders_policy ON orders
+  USING (get_current_user_id() = user_id);
+  -- get_current_user_id() called PER ROW
+  -- With 1M rows = 1M function calls
+```
+
+**Correct (function called once, result cached):**
+
+```sql
+CREATE POLICY orders_policy ON orders
+  USING ((SELECT get_current_user_id()) = user_id);
+  -- Wrapped in SELECT = called ONCE, result reused
+  -- 100x+ faster on large tables
+```
+
+For complex multi-table checks, use a `SECURITY DEFINER` helper:
+
+```sql
+-- Helper function runs as definer (bypasses RLS for lookups)
+CREATE OR REPLACE FUNCTION is_team_member(p_team_id bigint)
+RETURNS boolean
+LANGUAGE sql
+SECURITY DEFINER
+SET search_path = ''  -- Prevent search_path attacks
+AS $$
+  SELECT EXISTS (
+    SELECT 1 FROM public.team_members
+    WHERE team_id = p_team_id
+      AND user_id = (SELECT current_setting('app.current_user_id')::bigint)
+  );
+$$;
+
+-- Use in policy (indexed lookup, not per-row scan)
+CREATE POLICY team_orders_policy ON orders
+  USING ((SELECT is_team_member(team_id)));
+```
+
+**Always index columns used in RLS policies:**
+
+```sql
+CREATE INDEX orders_user_id_idx ON orders (user_id);
+CREATE INDEX team_members_lookup_idx ON team_members (team_id, user_id);
+```
+
+## Privilege Management
+
+Grant only the minimum permissions required. Never use superuser for application queries.
+
+**Incorrect (overly broad permissions):**
+
+```sql
+-- Any SQL injection becomes catastrophic
+GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO app_user;
+```
+
+**Correct (minimal, specific grants):**
+
+```sql
+-- Create roles with no default privileges
+CREATE ROLE app_readonly NOLOGIN;
+GRANT USAGE ON SCHEMA public TO app_readonly;
+GRANT SELECT ON public.products, public.categories TO app_readonly;
+
+-- Write role with limited scope
+CREATE ROLE app_writer NOLOGIN;
+GRANT USAGE ON SCHEMA public TO app_writer;
+GRANT SELECT, INSERT, UPDATE ON public.orders TO app_writer;
+GRANT USAGE ON SEQUENCE orders_id_seq TO app_writer;
+-- No DELETE permission
+
+-- Login role inherits from role groups
+CREATE ROLE app_user LOGIN PASSWORD 'secure_password_here';
+GRANT app_writer TO app_user;
+```
+
+Revoke public defaults (often forgotten):
+
+```sql
+REVOKE ALL ON SCHEMA public FROM public;
+REVOKE ALL ON ALL TABLES IN SCHEMA public FROM public;
+```
+
+## References
+
+- [Row Level Security](https://www.postgresql.org/docs/current/ddl-rowsecurity.html)
+- [Roles and Privileges](https://www.postgresql.org/docs/current/user-manag.html)
+- [Security Definer Functions](https://www.postgresql.org/docs/current/sql-createfunction.html#SQL-CREATEFUNCTION-SECURITY)