[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-sql
Subject:    FW: [SQL] Possible to emulate pre-8.2 behaviour of SET CONSTRAINTS?
From:       "Simon Kinsella" <simon () bluefiresystems ! co ! uk>
Date:       2007-01-22 10:50:15
Message-ID: 20070122105038.805CA19F306 () smtp07l ! fasthosts ! co ! uk
[Download RAW message or body]


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



---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not
       match
[prev in list] [next in list] [prev in thread] [next in thread]