Postgresql – Dangers in dropping all tables in a schema with CASCADE

cascadepostgresqlschema

The answer to this question suggests I can use the CASCADE option of DROP SCHEMA to remove all a schema and all its tables, but warns:

CASCADE – Automatically drop objects (tables, functions, etc.) that are contained in the schema, and in turn all objects that depend on those objects

Being a novice to databases, I'm unsure about what objects may depend on objects within a schema. Is it possible that a table or some other object outside the schema that is dependent on an object inside the schema will be dropped as well? If I just want to eliminate a schema and all its contents without changing anything else, is using CASCADE a good idea?

Best Answer

run it in a transaction, you'll get warnings for every cascading drop, ROLLBACK if don't like what you see.

Related Solutions

Postgresql – Dump PostgreSQL schema with foreign keys and referenced data

I am not aware of any tools to do exactly what you are asking right now. I want to suggest a few options you might have overlooked however that may meet your needs.

Database Cloning

If your database is not being used 24/7 you can clone it for test cases. This would be done using during times when the db is not in use:

createdb -U postgres new_dbname -T old_dbname

This does a file-level copy of the database, and so it preserves all data and is much faster than a dump and reload.

I very frequently use this technique for cases where I want to run test cases on one db where I can't guarantee that everything will roll back.

Base Backup and Restore

A second thing you can do if you want to bring all data onto another server is to set it up for replication as a master with at least one wal_sender, and use pg_base_backup to clone your db cluster over the network. Note this is a file-based clone, and so it will be a very network-intensive process (more than a dump) but restore will be a lot faster.

Writing your own Tool

One of the big difficulties in having a generally available tool is that cross-schema dependencies could be quite complex and handling all possible complexity is a bit of a daunting task. However for specific purposes this isn't too hard. I would recommend three steps, using pg_dump to get you most of the way there, and then having a script written in one language or another to add what we can hope are modest missing pieces. I think you could even do it with an sql script run through psql.

Dump schemas only of tables you need. Create new file. Something like: pg_dump -t mytable1 -t mytable2 -t mytable3 > my_partial_dump.sql
Export selected data to csv, and wrap using COPY statements. This could be done using psql along with echo and COPY TO STDOUT. This is appended to the partial dump.
Dump the schema as you are, and append this to the partial dump.

The advantage of a purpose-built tool if this is what you need is that you can manually manage the complex part of it and thus have a smaller, simpler tool than you might otherwise require.

PostgreSQL – How to Replace a Materialized View

As of PostgreSQL 9.4: Different to the documentation of CREATE VIEW, the documentation of CREATE MATERIALIZED VIEW does NOT mention the REPLACE keyword. There seems to be no shortcut aside from dropping all dependent objects and rebuilding each one.

When you do so, I can only recommend two small things:

Use DROP MATERIALIZED VIEW blabla CASCADE to get a list of all dependent objects
Do the drop and recreation of all dependent object in one transaction.

Best Answer

Related Solutions

Postgresql – Dump PostgreSQL schema with foreign keys and referenced data

PostgreSQL – How to Replace a Materialized View

Related Question