Convert DROP COLUMN SQL to pgroll operation

[ryanslade]

Part of #504

[ryanslade]

@andrew-farries What should we do about more complicated statements? The fun spec is:

DROP [ COLUMN ] [ IF EXISTS ] column_name [ RESTRICT | CASCADE ]

[andrew-farries]

@andrew-farries What should we do about more complicated statements? The fun spec is:

DROP [ COLUMN ] [ IF EXISTS ] column_name [ RESTRICT | CASCADE ]

In general we have to be careful to generate pgroll operations only when we're sure we won't lose information present in the SQL. In cases where there are extra options present in the SQL that we can't represent in the pgroll operation we should fall back to generating a raw SQL operation.

In this case:

• RESTRICT is the default behaviour, so we can safely generate the operation.
• CASCADE is not an option that op_drop_column currently supports so we have to fall back to raw SQL in case it is present. There are already tests for this kind of 'fall back to raw SQL' behaviour: https://github.com/xataio/pgroll/blob/main/pkg/sql2pgroll/alter_table_test.go?plain=1#L63-L92. We should add testcases here (and update the test name)

IF EXISTS is being ignored by the conversion to other operation types. This may or may not be the right behaviour, but we can follow it here and address it later for all operations.

[ryanslade]

@andrew-farries Thanks for the help, this is ready for review.

[ryanslade]

Once merged, do we mark the entry in the table at #504 with orange or green? We still fall back to raw sql in some cases so not sure if that is considered "done done"

[andrew-farries]

Once merged, do we mark the entry in the table at #504 with orange or green? We still fall back to raw sql in some cases so not sure if that is considered "done done"

I think we can set it to 🟢 . The 'fallback to raw sql' testcases serve as a good list of extra options for the respective pgroll operations to support, but we don't need to commit to supporting all of them as part of #504.