Renames

A table, view, sequence, function or column that was renamed shows in a comparison as one object missing on each side. Deployed as it stands, that drops one and creates the other, rows and all.

Declare the two as the same object and the deployment renames it instead, with its rows and history kept. Any other differences between the two are deployed as usual.

Spot a possible rename

A faint link icon after an object’s name marks a possible rename:

• On an object that is only on one side, when the other side has an unmatched object of the same kind.
• On a table on both sides, when it has unmatched columns on each side.

The icon’s tooltip says which action to use.

Declare a renamed object

1. Select the object that is only on one side.
2. Choose Same object as…, in the detail header or from the row’s right-click menu.
3. Choose the object it is on the other side. When there is only one candidate, it is chosen already.
4. For a table, pair its columns under Columns. See Columns of a renamed table.
5. Choose Pair and compare again.

Parallax saves the rename and compares again. The two objects now show as one row, Different, with a Rename tag: the target’s name struck through, then the source’s name.

Candidates come from the same schema, or from any schema when both sides name a schema.

On PostgreSQL, sequences named after the table, as a serial column’s is, are renamed with it.

Columns of a renamed table

The Columns section lists the source columns that do not pair by name. For each, choose the target column it was, or — new column —. Parallax fills in the obvious pairs, such as one unmatched column of the same type on each side. A target column can pair with one source column at most.

Target columns left unpaired are listed: a deployment drops them.

Declare renamed columns

1. Select a table that is on both sides.
2. Choose Renamed columns…, in the detail header or from the row’s right-click menu.
3. Pair each source column with the target column it was.
4. Choose Pair and compare again.

The detail header then shows “Renamed columns <old → new>”. Deploying renames the columns instead of dropping one and adding the other, so their values stay.

What follows the new name

Whatever is named after the table follows it: keys, checks and indexes (such as customers_pkey or PK_customers), PostgreSQL partitions (such as sales_2024), and a SQL Server history table (such as audits_history). Foreign keys that point at the table stay.

In the deploy wizard, renames run first, under -- Renames, and the review says “<n> rename(s) first, keeping the rows”.

Forget a rename

• On a renamed object, choose Not the same object. The two objects show on their own sides again.
• On a table with renamed columns, choose Forget the renamed columns.

Both compare again.

Where the pairing is kept

The pairing is kept on the project or pipeline and listed in its dialog under Same objects. Choose Forget this rename there to drop one; the next comparison shows the two objects again.

Once deployed, a rename is no longer needed and is ignored.

When a rename no longer applies

If a declared rename cannot apply, the comparison shows “A declared rename was not applied.” and says why. For example, one of the objects is no longer there, the two are in different schemas, or the target already has an object of the new name. The objects then compare as they are named. Forget the rename in the project or pipeline if it is no longer wanted.