ALTER TABLE DROP COLUMN rollback leaves column – what is the documented behavior in Firebird 4.0?

Direct answer

In Firebird 4.0 ALTER TABLE DROP COLUMN is transactional DDL. A ROLLBACK will attempt to revert the metadata changes, but the operation is documented as not fully reversible. You should not rely on rollback to restore the dropped column with its data.

Confirmed fact: Firebird 4.0 with ODS 13+ runs DDL inside the current transaction and logs metadata changes for rollback. The official documentation treats DROP COLUMN as having limited reversibility compared with ADD COLUMN.

Likely explanation, not a guarantee: after ROLLBACK the column definition can become visible again in RDB$RELATION_FIELDS and SHOW TABLE, because the metadata log is undone. Physical data pages for the dropped column are discarded during the DROP and are not recovered by rollback. If the metadata does reappear it is empty / NULL-filled, not the original values.

What the release notes imply

Transactional DDL was improved in Firebird 4.0, but DROP COLUMN remains a special case. The documentation consistently warns that dropping a column is not fully reversible and that data loss can be permanent even if the schema appears to roll back. There is no version-specific note in Firebird 4.0 that makes DROP COLUMN fully reversible.

Verification steps for this case

1. Start an explicit transaction and do not autocommit.

SET TRANSACTION;

2. Check the column exists before change.

SELECT RDB$FIELD_NAME FROM RDB$RELATION_FIELDS WHERE RDB$RELATION_NAME = 'TEST_TABLE' AND RDB$FIELD_NAME = 'TEST_COL';

3. Run the DDL in the same transaction.

ALTER TABLE TEST_TABLE DROP COLUMN TEST_COL;

4. Rollback the transaction.

ROLLBACK;

5. Re-check metadata and structure.

SELECT RDB$FIELD_NAME FROM RDB$RELATION_FIELDS WHERE RDB$RELATION_NAME = 'TEST_TABLE' AND RDB$FIELD_NAME = 'TEST_COL';

SHOW TABLE TEST_TABLE;

Also inspect dependent objects:

SELECT RDB$INDEX_NAME FROM RDB$INDICES WHERE RDB$RELATION_NAME = 'TEST_TABLE';

SELECT RDB$TRIGGER_NAME FROM RDB$TRIGGERS WHERE RDB$RELATION_NAME = 'TEST_TABLE';

If rollback does not restore the column

There is no built-in cleanup command beyond ROLLBACK. Full restoration requires manual recreation from saved DDL:

• Recreate the column with ALTER TABLE ADD COLUMN using the original type, nullability and default.
• Recreate indexes, triggers and constraints that referenced the column.
• Restore data from a backup, because the original values cannot be recovered from the dropped column.

Assumptions used here: Firebird 4.0, ODS 13+, default transactional DDL enabled, explicit transaction with autocommit off. Behavior is version and ODS dependent.

One diagnostic detail that changes the recommendation: is the database on ODS 13+ and was the ALTER executed in an explicit transaction with autocommit disabled? If autocommit was on, the DDL was committed immediately and ROLLBACK has no effect.