fix: EXPOSED-696 [PostgreSQL] Drop of auto-increment sequence fails after column modified without dropping default

[bog-walk]

Description

Summary of the change:
Add ALTER COLUMN ... DROP DEFAULT string to modified columns that lose their auto-increment status.

Detailed description:

• Why:

When a column is modified to no longer be auto-incrementing, MigrationUtils.statementsRequiredForDatabaseMigration() currently generates statements to ALTER the column type and DROP the associated sequence. If these statements are actually executed using PostgreSQL, they will fail with an exception like:

ERROR: cannot drop sequence test_table_id_seq because other objects depend on it
  Detail: default value for column id of table test_table depends on sequence test_table_id_seq
  Hint: Use DROP ... CASCADE to drop the dependent objects too.. Statement(s): DROP SEQUENCE IF EXISTS test_table_id_seq 

Before dropping the sequence, the default value of the no-longer-auto-incrementing column must also be dropped to ensure that the column no longer depends on it.

Note about Defaults:

Technically, metadata results correctly return a mismatch, with the existing column in the database having a default of something like nextval('test_table_id_seq'::regclass). But this line purposefully ignores the value, resulting in a technically incorrect ColumnDiff.defauts == false, so the necessary string isn't currently appended.

That line currently cannot be changed as it leads to failures in many other parts of the source code that depend on it.

• How:
  • Add branch to PostgreSQLDialect.modifyColumn() for condition when the existing column in the database is auto-incrementing but the defined column in the new table object is not.
  • Update ColumnDiff KDocs to be more clear.
  • Adjust test from previous PR fix!: EXPOSED-691 [PostgreSQL] Restrict dropping unmapped sequences to related tables only #2357

---

Type of Change

Please mark the relevant options with an "X":

• Bug fix

Affected databases:

• Postgres

Checklist

• Unit tests are in place
• The build is green (including the Detekt check)
• All public methods affected by my PR has up to date API docs
• Documentation for my change is up to date

---

Related Issues

EXPOSED-696
EXPOSED-691

[bog-walk]

Link to SchemaUtils.isIncorrectAutoInc that determines value of columnDiff.autoInc.

Also, I didn't keep the test for it, but I did confirm that appending the new string here does not affect migration to a new default, as logic further down would append ALTER COLUMN ... SET DEFAULT ... if needed. Meaning migrating from Column.autoIncrement() --> Column.default() would still succeed.