Re: RI triggers and schemas - Mailing list pgsql-hackers

From Jan Wieck
Subject Re: RI triggers and schemas
Date
Msg-id 200203262055.g2QKtwr26754@saturn.janwieck.net
Whole thread Raw
In response to Re: RI triggers and schemas  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: RI triggers and schemas  (Stephan Szabo <sszabo@megazone23.bigpanda.com>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: RI triggers and schemas
Next
From: "Nicolas Bazin"
Date:
Subject: Re: build of 7.2.1 on SCO Openserver and Unixware 7.1.1