| From: | Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net> |
|---|---|
| To: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: pointer to feature comparisons, please |
| Date: | 2007-06-13 22:29:40 |
| Message-ID: | 46706FD4.5090401@cox.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On 06/13/07 17:23, PFC wrote:
> On Thu, 14 Jun 2007 00:09:20 +0200, Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net>
> wrote:
>
>> On 06/13/07 16:59, PFC wrote:
>>>> Isn't it *supposed* to mis UNcommitted changes from other transactions?
>>> Well, if the "uncommited change" is a DELETE of the row that
>>> allowed the constraint check to pass, then when this delete is
>>> commited, your data is no longer consistent.
>>
>> The DELETE should block, no?
>
> Why ?
>
> Foreign keys put an ON DELETE trigger on the referenced table
Foreign keys that silently, automatic DELETE records?
Did I read that correctly?
> besides checking the referencing column on insert/update... If you just
> implement a constraint, you only get half the functionality.
But when I define a FK *constraint*, that's all I *want*!
--
Ron Johnson, Jr.
Jefferson LA USA
Give a man a fish, and he eats for a day.
Hit him with a fish, and he goes away for good!
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alejandro Torras | 2007-06-13 22:39:42 | Re: Using the GPU |
| Previous Message | PFC | 2007-06-13 22:28:39 | Re: inner join problem with temporary tables |