Re: [HACKERS] FOREIGN KEY !!!!!
От
Don Baccus
Тема
Re: [HACKERS] FOREIGN KEY !!!!!
Дата
Msg-id
3.0.1.32.20000205124742.00f991e0@mail.pacifier.com
Ответ на
Re: [HACKERS] FOREIGN KEY !!!!! (wieck@debis.com (Jan Wieck))
Список
Дерево обсуждения
FOREIGN KEY !!!!! wieck@debis.com (Jan Wieck)
Re: [HACKERS] FOREIGN KEY !!!!! Don Baccus <dhogaza@pacifier.com>
Re: [HACKERS] FOREIGN KEY !!!!! wieck@debis.com (Jan Wieck)
Re: [HACKERS] FOREIGN KEY !!!!! Don Baccus <dhogaza@pacifier.com>
At 09:30 PM 2/5/00 +0100, Jan Wieck wrote: >> o Under RESTRICT, by contrast, the system realizes "ahead of >> time" that row R2 exists and will violate the constraint if >> R1 is deleted, and so rejects the DELETE out of hand. > That'd mean in last consequence, that RESTRICT actions aren't > DEFERRABLE, while the rest of their constraint definition is! That's how I read it, too. Pardon me while I run off to vomit in the toilet. > Anyway, cannot work with the actual implementation of the > trigger queue, so we could either make RESTRICT and NO ACTION > identical (except for different ERROR messages), or leave the > SQL3 RESTRICT out of 7.0 while changing NO ACTION to fire the > message. > I'd prefer to have them identical in 7.0, because according > to Date they have no semantic difference, so it'll buy us > little if we complicate the trigger stuff more than required > right now. If others on the list agree, I think this is an excellent idea. I see no semantic difference that the application will see, either, other than a difference in execution time. Raising the exception before the delete or update seems more an efficiency hack than anything, i.e. it's much less expensive to short-circuit the delete/update rather than finish it, check afterwards, and roll it back. - Don Baccus, Portland OR Nature photos, on-line guides, Pacific Northwest Rare Bird Alert Service and other goodies at http://donb.photo.net.
В списке pgsql-hackers по дате отправления
От: Oleg Bartunov
Дата: