If you do this in production, be aware of prepared statements. Those have already been parsed, rewritten (and the query plan cached). The effect kicks until prepared statements are deallocated (which can take a long time).
To check for prepared statements (of the same session only!):
The effect also extends to plpgsql functions that handle SQL commands like prepared statements internally.
Normally, prepared statements are forced to be re-planned after any change to involved objects. But your actions circumvent this security mechanism.
Also, most queries will just keep working. But not all.
CREATE TEMP TABLE foo (id int);
INSERT INTO foo VALUES (4);
PREPARE x AS SELECT foo FROM foo WHERE id > $1; -- uses row type
ALTER TABLE foo ADD COLUMN t text;
EXECUTE x(3); -- automatically re-planned
But this does not:
ALTER TABLE foo RENAME TO foo1;
CREATE VIEW foo AS TABLE foo1;
ALTER TABLE foo1 ADD COLUMN t text;
EXECUTE x(3); -- not re-planned!
ERROR: cached plan must not change result type
The manual on
Although the main point of a prepared statement is to avoid repeated
parse analysis and planning of the statement, PostgreSQL will force
re-analysis and re-planning of the statement before using it whenever
database objects used in the statement have undergone definitional
(DDL) changes since the previous use of the prepared statement. Also,
if the value of
search_path changes from one use to the next, the
statement will be re-parsed using the new
search_path. (This latter
behavior is new as of PostgreSQL 9.3.) These rules make use of a
prepared statement semantically almost equivalent to re-submitting the
same query text over and over, but with a performance benefit if no
object definitions are changed, especially if the best plan remains
the same across uses. An example of a case where the semantic
equivalence is not perfect is that if the statement refers to a table
by an unqualified name, and then a new table of the same name is
created in a schema appearing earlier in the
search_path, no automatic
re-parse will occur since no object used in the statement changed.
However, if some other change forces a re-parse, the new table will be
referenced in subsequent uses.
The above is another example where the "semantic equivalence is not perfect".