Re: deferred constraints failing on commit

Can you send the full schema of the tables you are using for
this?

On Tue, 16 Jan 2001, Michael Richards wrote:

> Hi.
>
> I'm having trouble with committing a transaction. Intuitively it
> should work but does not.
>
> I've got a table with 2 foreign keys, minrev and maxrev. They refer
> to a the revisionid value in another table. I need to update the
> second table to reduce the revisionid, then insert a new row. At the
> end of this all the keys match up yet the commit fails.
>
> urdr=> begin;
> BEGIN
> urdr=> update objects set revisionid=2 where id=2 and
> revisionid=99999999;
>
> UPDATE 1
> urdr=> insert into objects
> (id,typeid,repositoryid,parentid,deleted,permissions,revisionid,name)
> values (2,2,1,NULL,'f',NULL,99999999,'test.sql');
> INSERT 246107 1
> urdr=> select id,revisionid from objects;
> id | revisionid
> ----+------------
> 1 | 99999999
> 2 | 1
> 2 | 2
> 2 | 99999999
> (4 rows)
> urdr=> select * from objcatalog ;
> objectid | repositoryid | minrev | maxrev | key | data
> ----------+--------------+----------+----------+----------+----------
> 2 | 1 | 99999999 | 99999999 | mimetype |text/plain
> (1 row)
>
> urdr=> commit;
> ERROR: <unnamed> referential integrity violation - key in objects
> still referenced from objcatalog
>
> At commit all the keys check out properly. minrev and maxrev both
> point to the same revisionid in the row we just inserted.
>
> Is this a bug or me just misreading how things should work again?
>
> -Michael
> _________________________________________________________________
> http://fastmail.ca/ - Fast Free Web Email for Canadians
>