2026-09-20 · 6 min read · Rahul Chitturi
- sql
- postgresql
- schema
A generated column derives its value from an expression declared in the table schema. It can centralize a searchable or normalized value, but applications often fail when they try to write that column directly or assume the deployed expression matches a local migration.
Version support and expression restrictions vary. A design copied from another database engine may use functions, dependencies, or virtual-versus-stored behavior that PostgreSQL does not accept.
Inspect the deployed expression
Read catalog metadata and the actual table definition rather than relying only on migration source. Compare generation kind, data type, collation, expression, referenced columns, indexes, constraints, and privileges.
- Confirm every function meets PostgreSQL's generation requirements.
- Check casts and collation for stable comparison behavior.
- Keep application INSERT and UPDATE column lists explicit.
- Verify ORM metadata after schema changes.
Distinguish recomputation from application defaults
Generated values follow their source columns according to database rules; they are not a one-time default copied at insert. Test source-column updates, bulk loads, replication, triggers, RETURNING, and restore workflows against the exact server version.
Indexes and constraints on a generated value can turn a source update into a uniqueness or size failure. Surface the named database error without logging sensitive row contents.
Migrate with representative rows
Use Flashman's SQL formatter for DDL and queries, JSON formatter for harmless row fixtures, diff for catalog output, and hash tool for deterministic public expression examples.
Test nulls, empty strings, Unicode, boundary lengths, casts, source updates, generated-column writes, indexes, uniqueness, partitioning, logical replication, dump and restore, old application versions, and rollback from each migration phase.