Add column as primary key creates mixed_objects unhandled deployment

[jfinzel]

ALTER TABLE foo ADD COLUMN bar_id SERIAL generates an unhandled deployment.

Here is why: here is what it shows:

 id |       set_name        |  pid  |   txid    | classid |  objid   | objsubid |   command_tag   | object_type | schema_name |                      object_identity                      | in_extension | set_config_id
----+-----------------------+-------+-----------+---------+----------+----------+-----------------+-------------+-------------+-----------------------------------------------------------+--------------+---------------
  1 | insert_update_special | 10795 | 960613833 |    1259 | 87397177 |        0 | CREATE SEQUENCE | sequence    | foo   | foo.bla_payments_bla_payment_id_seq | f            |             1
  2 | insert_update_special | 10795 | 960613833 |    1259 | 26311794 |        0 | ALTER TABLE     | table       | foo   | foo.bla_payments                            | f            |             1
  3 | insert_update_special | 10795 | 960613833 |    1259 | 87397177 |        0 | ALTER SEQUENCE  | sequence    | foo   | foo.bla_payments_bla_payment_id_seq | f            |             1
(3 rows)

EDIT: This perhaps cannot be supported with replication, because the serial value generated on the subscriber would be different.

There is only 2 ways I see to handle this:

1. User has to do this type of DDL in stages - add column, backfill it, then create and add the sequence with no DML involved, then swap the constraints
2. Remove the table from replication and re-add it after this operation, if such a brute force approach is acceptable.

The resolution to this may need to be for documentation only.