SQL RENAME TABLE: Check the New Schema Name Explicitly

The practice task

Rename a fictional pending_items table to review_queue. Use SQLite schema inspection to check which of the two names exists afterward.

The data below is fictional. Run the example in a new SQLite database. It was checked with SQLite 3.51.0; other databases may use different syntax, functions or type rules.

Complete worked query

Create the small fixture and run the query together. The IDs, boundary values and missing entries make the result small enough to check by hand.

CREATE TABLE pending_items(id INTEGER, label TEXT);
INSERT INTO pending_items VALUES (1,'draft outline');
ALTER TABLE pending_items RENAME TO review_queue;

SELECT name FROM sqlite_schema
WHERE type = 'table' AND name IN ('pending_items','review_queue')
ORDER BY name;

Checked result

This is the result of the exact example above. NULL marks a missing database value rather than the text string "NULL".

Read the result

The inspection returns review_queue and not pending_items. This checks the naming result directly. A table alias in a SELECT statement would not make that schema change; it would only provide a temporary query-local name.

The inserted draft-outline record belongs to the renamed table. Renaming is not a request to duplicate it into two separate tables. If a workflow needs an independent copy, define and test a copy operation instead of using a rename as a substitute.

References outside the database remain a separate concern. An application, export job or saved query may still use the old table name. Database handling of internal triggers, views and foreign-key references also depends on engine and version, so check those rules before adapting the operation.

Mistakes to check

Use these checks when adapting the example to a different dataset.

• Verify which schema name exists after the operation.
• Review external query strings and scheduled jobs.
• Do not confuse a table alias, rename and copy.