Re: RI triggers and schemas

Tom Lane wrote:

As of CVS tip, referential integrity triggers are kinda broken: they
will only work for tablenames that are in the current search path.
I think that instead of storing just table names in the trigger
parameters, we should store either table OIDs or schema name + table
name. Do you have any preferences about this?

An advantage of using OIDs is that we could forget the pushups that
ALTER TABLE RENAME presently goes through to update RI triggers.

On the other hand, as long as the RI implementation depends on
generating textual queries, it'd be faster to have the names available
than to have to look them up from the OID. But I seem to recall Stephan
threatening to rewrite that code at a lower level pretty soon, so the
speed issue might go away. In any case it's probably a minor issue
compared to generating the query plan.

So I'm leaning towards OIDs, but wanted to see if anyone had a beef
with that.

I'd go with OIDs too, because they're unambigous and don't
change.

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. Isn't that using oid's already,
ignoring the names? This requires a shortcut into SPI to
plan an existing parsetree.

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