Re: RI triggers and schemas

From: Jan Wieck <janwieck(at)yahoo(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jan Wieck <janwieck(at)yahoo(dot)com>, Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: RI triggers and schemas
Date: 2002-03-26 20:55:58
Message-ID: 200203262055.g2QKtwr26754@saturn.janwieck.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Jan Wieck <janwieck(at)yahoo(dot)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 though if 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. So for 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(at)Yahoo(dot)com #

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephan Szabo 2002-03-26 20:58:44 Re: RI triggers and schemas
Previous Message Tom Lane 2002-03-26 20:53:34 Indexes, TOAST tables, and namespaces