From the questing I believe you want to change or add partition column on an existing table, in this case ins_txn_attachment_live. One easy way I see and I personally follow when there is no option to alter a table for a specific property, like partition or change the position of fields inside a table is the following:

First rename your table and including keys or indexes (in addition do not give prefix of PK in PostgreSQL indexes, as PostgreSQL creates out of the box primary key indexes without being visible in PGAdmin):

ALTER TABLE ins_txn_attachment_live RENAME TO ins_txn_attachment_live_old
ALTER INDEX PK_Ins_TXN_Attachment_ID_ArchiveDataRENAME TO PK_Ins_TXN_Attachment_ID_ArchiveData_old

Then create your new table with the desired partition:

CREATE TABLE ins_txn_attachment_live (
    id              UUID         NOT NULL,
    attachment_id   UUID         NOT NULL,
    inserttstmp     timestamp    not NULL
    archivedate     timestamp    NULL
)PARTITION BY RANGE (<whatever column>);

Then copy your data from _old table to the new table (if the source and destination columns are the same):

INSERT INTO ins_txn_attachment_live SELECT * FROM ins_txn_attachment_live_old

Then copy your data from _old table to the new table (in case the source and destination columns are different):

INSERT INTO ins_txn_attachment_live (id, attachment_id, inserttstmp, archivedate, new_column) SELECT id, attachment_id, inserttstmp, archivedate, 'new_default_value' FROM ins_txn_attachment_live_old

Hope it helps

You can't alter the definition of a partition, but you can re-attach it with a different definition.

alter table stats_to_institution detach partition pqr_272;
alter table stats_to_institution attach partition pqr_272 
  for values FROM ('270000000') TO ('300000000'); --<< new upper bound

Obviously the data in that partition won't be visible in the main table between the detach and attach operation, but the data is still there.

Online example

PostgreSQL has to scan the table that is to be attached as a partition to verify that all rows fall into the partition boundaries. That can take a while for a large table. PostgreSQL can skip that check if there is already a fitting check constraint on the new partition:

ALTER TABLE segment_1_000_000_to_2_000_000
   ADD CHECK (k1 IS NOT NULL AND number >= 1000000 AND number < 2000000);

If number is defined as NOT NULL, the first check can be omitted.

You can verify that your constraint was good by setting client_min_messages to debug1, then the ALTER TABLE ... ATTACH will emit a message like

DEBUG:  partition constraint for table "DEBUG:  partition constraint for table "x1" is implied by existing constraints" is implied by existing constraints