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-printor hand it to the trigger as argument. Isn't that using oid's already, ignoring the names? This
requiresa 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
