Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id BF0002E003D for ; Sat, 7 Jun 2008 14:38:51 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 37778-01 for ; Sat, 7 Jun 2008 14:38:45 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail129178.authsmtp.co.uk (outmail129178.authsmtp.co.uk [62.13.129.178]) by developer.postgresql.org (Postfix) with ESMTP id 07AD42E0039 for ; Sat, 7 Jun 2008 14:38:46 -0300 (ADT) Received: from mail-c188.authsmtp.com (mail-c188.authsmtp.com [62.13.128.25]) by punt3.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id m57Hcg11099044; Sat, 7 Jun 2008 18:38:42 +0100 (BST) Received: from [192.168.0.3] (85-211-65-92.dyn.gotadsl.co.uk [85.211.65.92]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id m57HcfHa069447; Sat, 7 Jun 2008 18:38:41 +0100 (BST) Subject: Re: pg_dump restore time and Foreign Keys From: Simon Riggs To: Robert Treat Cc: pgsql-hackers@postgresql.org, Andrew Dunstan In-Reply-To: <200806071308.00845.xzilla@users.sourceforge.net> References: <1212647003.19964.19.camel@ebony.site> <4847D4A7.70309@dunslane.net> <1212670595.19964.55.camel@ebony.site> <200806071308.00845.xzilla@users.sourceforge.net> Content-Type: text/plain Date: Sat, 07 Jun 2008 18:41:55 +0100 Message-Id: <1212860515.12046.78.camel@ebony.site> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 Content-Transfer-Encoding: 7bit X-Server-Quench: 91e35dbd-34b8-11dd-aecc-001871e930f4 X-AuthRoute: OCdxZQATClZOTQEd DAteCiNZVAwpPBRK HVkIKg5MJUcNSQVJ NksadRtFaAJbZ0xf HGQLW1xEUVV7Wmt/ bwsfZQBDYEtPQQNv TkFLXVBXFgB3AVJc AxlmAU8KJgVAcXp0 YghgXXJZEk17IEV4 FhwACG4CN299aWFL BF0JIlAHbQNKfxdC awV2V3NbZStlM3Bw LC8aFBMcBw5qYDxa dQ0QKEpaW0sQAjkm SlgeHDAiVUQDS20d KAYrK1EaVGUcI15a X-Authentic-SMTP: 61633235383639.cat.dmpriest.net.uk:1045/Kp X-Report-SPAM: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-Virus-Status: No virus detected - but ensure you scan with your own anti-virus system! X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200806/341 X-Sequence-Number: 119454 On Sat, 2008-06-07 at 13:08 -0400, Robert Treat wrote: > On Thursday 05 June 2008 08:56:35 Simon Riggs wrote: > > On Thu, 2008-06-05 at 07:57 -0400, Andrew Dunstan wrote: > Heh, I would have argued that the idea should go the other way and > just make this part of the normal syntax. Oracle DBA's have been > doing this for years (MS SQL supports it too actually) and it really > helps working around having to hold locks on large relations for > lengthy periods of times. Heck, I'd like to see a no check option for > all constraints really. Interesting that SQL Server does it also. Holding the lock for a long period is just one more problem. :-) I'm always torn between the I-know-what-Im-doing-so-give-me-the-option viewpoint and the some-dumbass-will-abuse-it viewpoint. I see the results of both viewpoints daily. Perhaps we need a GUC that says expert_mode = on. In expert_mode we are allowed to do a range of things that are normally avoided - there would be an explicit list. Managers can then take a single considered decision as to whether the situation warrants extreme action and their DBA is good enough to handle it. That might resolve our continued angst about whether our users our smart enough to avoid the gotchas, or just smart enough to win a DBA's Darwin Award. The UNIX philosophy has always been to allow the power to exist, yet seek to minimise the number of people who exercise it. Another idea might be to make such command options superuser only, to ensure the power is available, yet only in the hands of, by-definition, the trusted few. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support