y story: your side, their side, the
truth, and what really happened.
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
To: "Rod Taylor" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, April 06, 2001 11:20 AM
Subject: Re: [HACKERS] For
"Rod Taylor" <[EMAIL PROTECTED]> writes:
> I must apologize, I was copying from one screen to another due to
> network outage and gave a bad example -- missed the most important
> part.
> There should have been an AS ON DELETE TO junk DO INSTEAD NOTHING;
> rule.
Ah so. With that in place, I see
"Rod Taylor" <[EMAIL PROTECTED]> writes:
> Not quite as expected. I didn't expect deleting the 2 from the
> primary table to fail because the CASCADE DELETE wasn't able to run on
> the second (even though no values existed in that table).
But it *doesn't* fail. At least not in the versions I tr
--- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
To: "Rod Taylor" <[EMAIL PROTECTED]>
Cc: "Hackers List" <[EMAIL PROTECTED]>
Sent: Friday, April 06, 2001 1:54 AM
Subject: Re: [HACKERS] Foreign Key & Rule confusion WAS: Lost
Trig
"Rod Taylor" <[EMAIL PROTECTED]> writes:
> Found the issue. Try out the attached SQL in a fresh database.
And? AFAICT it behaves as expected, in either 7.0.2 or current ...
regards, tom lane
---(end of broadcast)---
TIP 2
Found the issue. Try out the attached SQL in a fresh database.
I had honestly expected the second delete to work properly as nothing
had to be removed that table.
The rule was added as a temporary measure to protect the data
currently in the table -- without the intent of otherwise impeding the
