hello again everyone,
I seem to have hit what i -think- may be a bug (but i am not crying
wolf jst yet ;).
I have three tables. action, client and order_details. action has a primary
key 'order', client references action (along with adding the client_id as
part of its primary key), order_details references client (both parts of the
primary key there). all foreign keys (order in client and order+client_id in
order_details) are set to INITIALLY DEFERRED. so far so good i hope.
Now, i have a trigger that fires on insert, so i delete from the live
database and then insert the changes rather than doing an update. not
great, but shouldnt be a problem.
The problem comes when i do this:
mms_post=# BEGIN;
BEGIN
mms_post=# DELETE from client WHERE order_id = 22;
DELETE 1
mms_post=# INSERT INTO client
mms_post-#(cli_business_name,cli_chain_id,cli_business_type,cli_short_name,cl
i_sic,order_id,client_id,cli_agent_bank_id,cli_operating_name,creation_id,cli_
web_page,cli_tcc,creation_date)
mms_post-# VALUES ('STEFS','100-000000000333',1,'FHASDLKJH HFAKSDJ
HKALSDJ',2534,22,'100-00000000555',230,'FHASDLKJH HFAKSDJ
HKALSDJFH','jack','[EMAIL PROTECTED]','R','2001-06-18 13:46:45-04');
INSERT 24211 1
mms_post=# COMMIT;
ERROR: <unnamed> referential integrity violation - key in client still
referenced from order_details
Now. the way i understand it, shouldnt the integrity of any foreign keys
be checked at the -end- of the transaction, after all the commands have been
processed ? it seems that the DELETE is being processed and rejected, but
the foreign key would be 'okay' due to the following INSERT. I have tried
SET CONSTRAINTS as well with no difference :\
Does this make any sense or am i completely mad ? (more than likely)
regards,
Stefs.
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
