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. #
#================================================== [EMAIL PROTECTED] #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
