Re: RI triggers and schemas
От | Jan Wieck |
---|---|
Тема | Re: RI triggers and schemas |
Дата | |
Msg-id | 200203262055.g2QKtwr26754@saturn.janwieck.net обсуждение исходный текст |
Ответ на | Re: RI triggers and schemas (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: RI triggers and schemas
|
Список | pgsql-hackers |
Tom Lane wrote: > Jan Wieck <janwieck@yahoo.com> writes: > > Actually I'm kicking around a slightly different idea, how to > > resolve the entire problem. We could build up the > > querystring, required to do the check, at trigger creation > > time, parse it and store the querytree node-print or hand it > > to the trigger as argument. > > Hm. Seems kinda bulky; and the parse step alone is not that expensive. > (You could only do raw grammar parsing I think, not the parse analysis > phase, unless you wanted to deal with having to outdate these stored > querytrees after changes in table schemas.) You're right, as soon as other details than the column or table name might change, this could get even more screwed. > I think the existing scheme of generating the plan during first use > in a particular backend is fine. At least as long as we're sticking > with standard plans at all ... IIRC Stephan was wondering about > bypassing the whole parse/plan mechanism in favor of heap-access-level > operations. I don't know if using heap-access directly in the RI triggers is such a good idea. It is guaranteed that there is a unique key covering all the referenced columns (and only them). I'm not sure thoughif it has to be in the same column order as the reference. Nor do I think that matters other than making the creation of the scankey a bit more difficult. But there could be no, some, a full matching index, maybe one with extra columns at the end on the foreign key. Sofor the referential action, the entire process of deciding which index fits best, pushing some of the qualification into the index scankey, and do the rest on the heap tuples, has to be duplicated here. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com # _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
В списке pgsql-hackers по дате отправления: