Development

ForgeSchema Second Alpha Handles Real PostgreSQL Schemas

The first alpha could only read a schema if it had no defaults, no identity columns, no unique constraints and no foreign keys. That’s almost no real database. Point it at a typical app schema and it said “unsupported” and stopped.

v0.2.0-alpha.1 fixes that.

ForgeSchema now reads and writes varchar, char and numeric columns, defaults like now(), current_date and gen_random_uuid(), identity columns, unique constraints, unique indexes and foreign keys with their ON DELETE and ON UPDATE actions. Inspect, plan, apply and verify all understand them. The shop example uses every one: customers with an identity key and a unique email, orders that reference customers, order lines that cascade when an order goes.

ForgeSchema workflow

More changes it can plan

Plans can now add a required column as long as it has a default, widen a varchar or numeric column, make a column required or optional, change a default, and add unique constraints, indexes and foreign keys to tables that already hold data. Each step says what PostgreSQL will do with existing rows. A now() default gives every old row the time of the migration. A gen_random_uuid() default rewrites the whole table. If existing data breaks the change (a NULL where you asked for NOT NULL, a duplicate under a new unique constraint, an order pointing at a missing customer) the whole migration rolls back and tells you why.

Drops and most type conversions are still blocked. Deliberately.

Gentler on a live database

Apply used to lock every table in the schema, even the ones it wasn’t touching. Now it locks only the tables a plan changes, and plan --explain lists them before you run anything. Slow steps like an index build on a big table can get more time with --lock-timeout, --statement-timeout and --timeout. When something fails you get PostgreSQL’s own message and error code, not a generic “migration failed”.

Found in review

An independent review turned up a real security bug before release. A text default with a backslash in it could slip SQL into a migration on servers running with standard_conforming_strings off. ForgeSchema now rejects those defaults and forces the setting on for its own transactions. The review also caught defaults that verify would have called a match when PostgreSQL actually stored something else. That’s fixed too.

Plans saved with the first alpha still load and apply unchanged.

Binaries for Linux, macOS and Windows are on the download page. Read the capability matrix before you point it at a database you care about.