Message-ID: <3F0C67BA.2050209@Yahoo.com>
Date: Wed, 09 Jul 2003 15:06:34 -0400
From: Jan Wieck <JanWieck@Yahoo.com>
Organization: Unorganized
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.0.2) Gecko/20030208 Netscape/7.02
MIME-Version: 1.0
To: Stephan Szabo <sszabo@megazone23.bigpanda.com>
Cc: Rudi Starcevic <rudi@oasis.net.au>, pgsql-sql@postgresql.org
Subject: Re: Break referential integrity.
References: <20030701211322.L66304-100000@megazone23.bigpanda.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Stephan Szabo wrote:
> On Wed, 2 Jul 2003, Rudi Starcevic wrote:
> 
>> Hi,
>>
>> I know that if you have a trigger and function then drop/replace the
>> function the trigger needs
>> to be drop/replaced too so that it can see the new function.
>>
>> Is it the same for Ref. Integ. on table's too ?
>>
>> If table B's foreign key references table A and you drop/replace table A
>> then the reference from table B to table A is broken and needs to be
>> recreated ?
> 
> In recent versions, you should not be drop table A without specifying
> cascade which will drop the constraint for you (and thus you'll need to
> recreate it).  In older versions, I'm not 100% sure what'd happen, but you
> probably should drop and recreate it for good measure.

Older versions spit out a NOTICE and dropped the constraint, so they 
kinda defaulted to CASCADE.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #