Add a "Duplicate row" action to the Table Editor

[Mohammed-Saif-Ibrahim]

Feature request

Add a "Duplicate row" action to the Supabase Studio Table Editor.

Proposed behavior

From the row context menu, users should be able to select "Duplicate row" to create a new row based on an existing row.

The workflow would be:

1. Right-click a row in the Table Editor.
2. Select "Duplicate row".
3. Open the row editor side panel with the existing row's values pre-filled.
4. Exclude primary key values so that a new record can be created with fresh primary key values.
5. Clearly indicate that the user is duplicating a row, e.g. "Duplicate row in <table>".
6. On save, insert the duplicated values as a new row rather than updating the original row.

Why

When users need to create a new record with values similar to an existing record, they currently have to manually copy the values into a new row. A dedicated Duplicate row action would make this workflow faster and more intuitive.

Considerations

The behavior should account for database-specific constraints and column behavior, including:

• Primary key columns and generated primary keys
• Foreign key values, which may be copied from the original row
• Auto-generated/default columns such as timestamps or identity columns
• Database constraints that may prevent the duplicated row from being inserted
• Appropriate success and error feedback when the operation completes or fails

Status

I've already put together a working implementation of this on a branch, including handling for the considerations above (friendlier error messaging when a duplicated row hits a constraint, a distinct success message, etc.). Happy to open a PR if this is a direction the team is interested in — just wanted to check on the design/approach first per the contributing guidelines.

[Mohammed-Saif-Ibrahim]

Just wanted to bump this in case it slipped through — happy to share more detail if useful.

A couple of things I didn't mention initially that might help clarify scope:

• The implementation reuses the existing row editor side panel rather than introducing new UI, so the surface area for review should be relatively small.
• Error handling was a specific focus — duplicate rows that hit a unique or FK constraint on insert get a distinct, friendly error message instead of the generic insert failure, and successful duplication gets its own success toast (separate from the regular "row updated" one) so it's clear a new row was created.

No rush at all — just didn't want it to get lost. Let me know if a different approach or more context would help move this forward.