Support for converting SQL DDL statements to pgroll migrations is partially complete. This issue tracks progress towards completion.

Support matrix

Operation	Status	Notes	PRs
create_table	🟠	[1]	#502, #546, #547, #548, #549, #550, #552, #553, #554, #555, #556, #557, #559, #560, #561, #563, #585
rename_table	🟢		#513
drop_table	🟢		#529
add_column	🟢		#544, #558, #562
drop_column	🟢		#521
alter_column (rename column)	🟢		#511
alter_column (change type)	🟢		#506, #508
alter_column (set not null)	🟢		#502
alter_column (drop not null)	🟢		#505
alter_column (set_unique)	🟢		#507
alter_column (set comment)	n/a	[3]
alter_column (set default)	🟢		#526, #535
alter_column (drop default)	🟢		#526
create_index	🟢		#551
drop_index	🟢		#524
rename_constraint	🟢		#514
drop_constraint	n/a	[2]
set_replica_identity	n/a	[4]
drop_multicolumn_constraint	🟢	[6]	#536
create_unique_constraint	🟢		#507
create_check_constraint	🟠	[5]	#538
create_foreign_key_constraint	🟢		#531

Notes

[1]: remaining:

• multi-column primary keys
• foreign keys (single and multi-column)
• check constraints (single and multi-column)
• default column values

There are also many `CREATE TABLE` options that are not representable by `OpCreateTable`; we need to ensure we fall back to raw SQL if any such options are present.

[2] :drop_constraint is deprecated, sql2pgroll should generate only drop_multicolumn_constraint operations.

[3]: we probably don't want to support this; the default behaviour of generating a raw SQL operation is sufficient for this

[4]: the operation is deprecated, falling back to raw sql for the `SET REPLICA IDENTITY` syntax is acceptable.

[5]: Conversion of `ALTER TABLE ... ADD CONSTRAINT ... CHECK` statements currently uses placeholders for the names of the columns covered by the constraint and for keys (column names) in the `up`/`down` data migration map. We should investigate whether it is possible to walk the AST for the `CHECK` expression (possibly using reflection) to discover the names of the covered columns instead.

[6]: Dropping constraints are tricky because they may affect more than a single column. When creating a pgroll operation to do this (`OpDropMultiColumnConstraint`) we need to specify all the affected columns so that we can create the required triggers. A simple `DROP CONSTRAINT` expression does not contain enough context to allow us to infer the affected columns.