Renaming Tables Safely in DataGrip: A Practical Refactor Guide

Problem: Renaming a Table in a Live Database

When a business decision forces a table name change – for example, orders to purchase_orders – the change must ripple through every view, trigger, stored procedure, and even application code that references it. A manual, copy‑paste approach is error‑prone and time‑consuming. DataGrip’s Refactor | Rename (Shift+F6) promises to do the heavy lifting, but only if you understand how it works and what it can’t catch.

What DataGrip’s Rename Does (and Doesn’t)

DataGrip’s rename engine performs a static analysis of the SQL code in the current project. It scans:

• Table, column, and alias definitions
• Views, materialized views, and derived tables
• Triggers, stored procedures, and functions
• DDL statements that reference the object

Once the dependencies are collected, the IDE builds a Refactor Preview window. Here you see every DDL statement that will be executed – ALTER TABLE, CREATE OR REPLACE VIEW, and so on – before you click Refactor. The generated SQL is adapted to the specific dialect of the connected database, so PostgreSQL, MySQL, and SQL Server all get the right syntax.

However, the engine only sees what’s in the source files. Dynamic SQL built at runtime (e.g., EXECUTE 'SELECT * FROM ' || table_name) will not be detected, and references in external scripts or application code outside the IDE remain untouched.

Step‑by‑Step Example – Renaming a PostgreSQL Table

1. Open the project in DataGrip and connect to the target PostgreSQL database.

2. Locate the table in the Database view. Right‑click public.orders and choose Refactor | Rename (Shift+F6).

3. Enter the new name – purchase_orders – and hit Enter. DataGrip will scan for dependencies.

4. Review the Refactor Preview pane. It should list something like:

   ALTER TABLE public.orders RENAME TO purchase_orders;
   CREATE OR REPLACE VIEW public.latest_orders AS
       SELECT * FROM public.purchase_orders WHERE order_date > CURRENT_DATE - INTERVAL '7 days';
   

5. Make sure the generated statements match your expectations. If a view or procedure references the old name, the preview will contain a CREATE OR REPLACE statement that updates it.

6. Click Refactor. DataGrip will execute the DDL statements in a single transaction.

7. Verify the rename:

   • Run SELECT * FROM public.purchase_orders LIMIT 5; to confirm the table exists.
   • Query the view: SELECT * FROM public.latest_orders; – it should return rows without errors.

8. If you’re using a version control system, commit the updated view or procedure files. DataGrip does not automatically touch external scripts.

Trade‑offs and Limitations

• Permissions: The rename requires ALTER rights on the table and CREATE rights on any dependent objects. In a production environment, this may lock the table for the duration of the transaction.
• Dynamic SQL: Any reference to the old table name inside application code or stored procedures that build SQL strings at runtime will break after the rename. You must audit those code paths manually.
• External Files: DataGrip’s preview only covers objects stored in the IDE’s project directory. Scripting files outside the project (e.g., in a shared CI/CD repository) won’t be updated.
• Large‑Scale Renames: Renaming thousands of tables or columns in a single refactor can overwhelm the preview pane and increase the risk of accidental changes. Consider splitting the operation into smaller batches.

Actionable Checklist Before You Commit

1. Run a full database test suite after the rename to catch runtime SQL errors.
2. Use pg_dump -s or an equivalent to generate a schema dump and compare the pre‑ and post‑rename versions for unexpected changes.
3. If you’re in a CI/CD pipeline, add a step that runs the Refactor Preview script and asserts that no new DDL statements appear beyond those you expect.
4. Back up the database before the rename, or perform the operation in a staging environment that mirrors production.
5. Document the change in your change‑log and notify any teams that maintain application code.

By following these steps, you can leverage DataGrip’s powerful refactor engine to rename tables safely, while staying aware of the dynamic SQL and external file caveats that can otherwise lead to silent failures.