Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1ZLv4v-0000hb-9G for pgsql-sql@arkaria.postgresql.org; Sun, 02 Aug 2015 15:21:33 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1ZLv4u-0006KP-57 for pgsql-sql@arkaria.postgresql.org; Sun, 02 Aug 2015 15:21:32 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1ZLv3u-0005EI-ES for pgsql-sql@postgresql.org; Sun, 02 Aug 2015 15:20:30 +0000 Received: from plane.gmane.org ([80.91.229.3]) by makus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1ZLv3m-0008VX-Q2 for pgsql-sql@postgresql.org; Sun, 02 Aug 2015 15:20:28 +0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ZLv3j-0005g1-Ch for pgsql-sql@postgresql.org; Sun, 02 Aug 2015 17:20:19 +0200 Received: from ppp-46-244-192-101.dynamic.mnet-online.de ([46.244.192.101]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 02 Aug 2015 17:20:19 +0200 Received: from spam_eater by ppp-46-244-192-101.dynamic.mnet-online.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 02 Aug 2015 17:20:19 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: pgsql-sql@postgresql.org From: Thomas Kellerer Subject: Re: Getting the list of foreign keys (for deleting data from the database) Date: Sun, 2 Aug 2015 17:20:08 +0200 Lines: 54 Message-ID: References: <55BE3180.5020600@splivalo.hr> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ppp-46-244-192-101.dynamic.mnet-online.de User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.21) Gecko/20090302 Thunderbird/2.0.0.21 Mnenhy/0.7.5.666 In-Reply-To: <55BE3180.5020600@splivalo.hr> X-Pg-Spam-Score: -2.4 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-sql Precedence: bulk Sender: pgsql-sql-owner@postgresql.org Mario Splivalo schrieb am 02.08.2015 um 17:04: > Suppose I have a table_detail that has column table_id which is FK > pointing to table(id), I would need to do something like this: > > SELECT foo_drop_all_constraints(); > SELECT * FROM table INTO table_copy WHERE date_created >= '2015-01-01'; > SELECT table_detail.* INTO table_detail_copy FROM table_detail JOIN > table_copy ON table_detail.table_id = table_copy.id > DROP TABLE table; > DROP TABLE table_copy > ALTER TABLE table_copy RENAME TO table; > ALTER TABLE table_detail_copy TO table_detail; > SELECT foo_restore_all_constraints(); > > Now, what am I asking is - is there a tool which would help me find all > the _detail tables? I know I could query pg_constraints and similar > views but before I go onto hacking into those I'm wondering if there is > something that could aid me in doing so. The SQL tool I maintain (http:://www.sql-workbench.net) has such a feature. It supports a (SQL Workbench specific) command that generates (recursively) the delete statements starting with the "root" table given a condition on the root table: http://www.sql-workbench.net/manual/wb-commands.html#command-gendelete The generated SQL script honors the FKs and thus there is no need to drop all constraints. In your case it would be something like: WbGenerateDelete -table=root_table -columnValue="date_created >= '2015-01-01'"; The output is a script with the DELETEs in the right order - or at least it _should_. I have to admit that I had to deal with one or two really large schemas (> 700 tables) where the delete statements where not ordered properly, especially if there are multiple FKs to/from the same table. Note that the generated statements are not pretty and far from being efficient. > Of course, if this is not the best approach I'd appreciate different > views/opinions. In my experience, setting all the FKs to "on delete cascade" and properly indexing the FK columns is very often faster than doing the deletes all "manually". Another option (if you need to do that very often) is to partition the tables by e.g. year. Then getting rid of all the data for a year is as simple as dropping the partitions for that year. However partitioning and foreign key constraints don't work together in Postgres, which is a real shame. Thomas -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql