I have a very central table in our database that is used by a range of applications, it has rules attached to it, triggers and all the dependencies that you can imagine. Now I would like to modify the table without causing any problems with the dependencies. I have previously been successful with doing the following but in a much less complex case:
alter table reconciliations rename to matches;
create view reconciliations as select * from matches;
What this achieves is that I could now modify the new "matches" table and for example add a column or rows, which do not need to get presented in the "reconciliations" view (by adding a where clause to filter them out).
I am on Postgres 9.5 so the view is automatically updatable. Initial tests shows that there are no immediate problems with this, so I am asking this question to know what kind of problems I should be looking for. Performance is not a big issue.
Best Answer
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.
Demo
This works:
But this does not:
The manual on
PREPARE
:The above is another example where the "semantic equivalence is not perfect".