Date: Mon, 24 Feb 2003 15:38:49 -0800
Mime-Version: 1.0 (Apple Message framework v551)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Subject: Problem with deferred referential integrity checks
From: Bob Smith <bsmith@h-e.com>
To: pgsql-sql <pgsql-sql@postgresql.org>
Content-Transfer-Encoding: 7bit
Message-Id: <1FADF813-4851-11D7-A2BB-0003933DD370@h-e.com>

I'm running Postgres 7.2.1 on MacOS X Server 10.1.5.  Here's the 
problem I'm having, by way of a simplified example.  First create some 
tables and data:

   create table table1 (
     key int primary key,
     data text
   );

   create table table2 (
     table1key int references table1 deferrable initially deferred,
     moredata text
   );

   insert into table1 values (1, 'Item 1');
   insert into table1 values (2, 'Item 2');

   insert into table2 values (1, 'References Item 1');
   insert into table2 values (2, 'References Item 2');

Now try to make a change:

   begin work;
   delete from table1 where key = 1;
   insert into table1 values (1, 'Changed Item 1');
   commit;

   ERROR:  <unnamed> referential integrity violation - key in table1 
still
   referenced from table2

I don't understand this, it doesn't seem like there should be a 
referential violation.  At the end of the transaction, there is a row 
in table1 which satisfies every reference from table2.  On the other 
hand, the following does work:

   begin work;
   delete from table1 where key = 1;
   insert into table1 values (3, 'Changed Item 1');
   update table2 set table1key = 3 where table1key = 1;
   commit;

No error.  In this transaction the deferred referential check sees the 
inserted row, but in the previous one it does not.  Is this intentional 
for some reason, a limitation of Postgres, a bug, or am I just not 
"getting it"?

Obviously in this example the change could be done as an update, 
avoiding the problem entirely.  But the real database I'm working with 
is much more complicated and an update isn't possible.  I can solve the 
problem by generating new primary keys for all rows in table1 each time 
there is any change, thus making all transactions look like the second 
one above, but that causes other problems which I'd like to avoid.  Any 
other suggestions?

Thanks for any help!

Bob Smith
Hammett & Edison, Inc.
bsmith@h-e.com