Thread

1. Possible bug in 'set constraints all deferred';

   David Jack Olrik <david@olrik.dk> — 2000-08-09T12:54:10Z

   Hi,
   
   I think I have found a bug in the handeling of 'deferred
   contraints'. I have attached a small sql script that reproduces the
   error.
   
   The first transaction succedes, but the second one failes with
   'psql:bug.sql:58: ERROR:  <unnamed> referential integrity violation -
   key in p still referenced from c'
   
   Isn't it supposed succed just like the first one ??
   
   -- 
   Best regards,
   David Jack Olrik <david@olrik.dk>     http://david.olrik.dk
   GnuPG key C290 0A4A 0CCC CBA8 2B37 E18D 01D2 F6EF 2E61 9894
   [ GNU Software: 'The source will be with you ... Always!' ]
   
   

2. Re: Possible bug in 'set constraints all deferred';

   Jan Wieck <janwieck@yahoo.com> — 2000-08-09T19:20:45Z

   David Jack Olrik wrote:
   > Hi,
   >
   > I think I have found a bug in the handeling of 'deferred
   > contraints'. I have attached a small sql script that reproduces the
   > error.
   >
   > The first transaction succedes, but the second one failes with
   > 'psql:bug.sql:58: ERROR:  <unnamed> referential integrity violation -
   > key in p still referenced from c'
   >
   > Isn't it supposed succed just like the first one ??
   
   [Attachment, skipping...]
   
       WRT  the  primary key constraint, this should be considered a
       "triggered data change  violation",  and  the  system  should
       already complain at the INSERT attempt's for p.
   
       We  don't  track  it that precise. So the error message isn't
       the right one and  it  happens  too  late.  But  the  overall
       transactional behaviour is correct.
   
   
   Jan
   
   --
   
   #======================================================================#
   # It's easier to get forgiveness for being wrong than for being right. #
   # Let's break this rule - forgive me.                                  #
   #================================================== JanWieck@Yahoo.com #