From: "Simon Kinsella" <simon@bluefiresystems.co.uk>
To: <pgsql-sql@postgresql.org>
Subject: FW: Possible to emulate pre-8.2 behaviour of SET CONSTRAINTS? 
Date: Mon, 22 Jan 2007 10:50:15 -0000
Organization: Bluefire Systems Ltd
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: Acc91o4erYN7B1RXQR6GEAlUUrVcyQAMPR4gAALjjnA=
Message-Id: <20070122105038.805CA19F306@smtp07l.fasthosts.co.uk>


That sounds like a plan - will give it a go. Thanks!

simon 

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Monday, January 22, 2007 3:37 AM
To: Simon Kinsella
Cc: pgsql-sql@postgresql.org
Subject: Re: [SQL] Possible to emulate pre-8.2 behaviour of SET CONSTRAINTS?


"Simon Kinsella" <simon@bluefiresystems.co.uk> writes:
> My system currently runs on PostgreSQL 8.1 and makes use of the old 
> behaviour of SET CONSTRAINTS, namely that the command is applied to 
> all constraints that match the specified name.

Unfortunately that was pretty far away from what the SQL spec says :-(

> This makes it very easy to write
> a general-case function that can change the DEFERRED mode on a given 
> constraint that is present in several similar schemas (sounds odd 
> maybe but it works very well in my case!).

I think you could do it fairly easily still, eg

	for rec in select nspname from pg_namespace n join pg_constraint c
on n.oid = c.connamespace where conname = $1 loop
           execute 'set constraints ' || quote_ident(rec.nspname) || '.' ||
quote_ident($1) || ' immediate';
        end loop;

Exceedingly untested, but something close to this seems like it'd solve your
problem.

			regards, tom lane