Re: example of really weird caching (or whatever) problem

d == dev(at)archonet(dot)com writes:

d> Brandon Metcalf wrote:
d> > Here is an example of the caching problem I described yesterday in a
d> > post. I have the following tables:

d> > And here is the SQL for the function and trigger definitions:
d> >
d> > CREATE OR REPLACE FUNCTION bmetcalf.foo_func()
d> > RETURNS TRIGGER
d> > LANGUAGE plperlu
d> > AS $$
d> > require 5.8.0;
d> >
d> > my $table = $_TD->{relname};
d> > warn "table name is $table";
d> > warn "BWM before call: table name is $table";
d> >
d> > do_delete();
d> >
d> > return 'SKIP';
d> >
d> > sub do_delete {
d> > warn "BWM in call: table name is $table";
d> > }
d> >
d> > $$;

d> Umm - you've got a named closure inside your funciton here - "sub
d> do_delete".

d> It's warning isn't using the "my $table" variable, it's using a
d> localised copy of that variable. That gets defined when the sub is
d> defined, which will be on the first call (my $table=foo2) and still
d> exists, unchanged on the second call (my $table=foo1).

Yep, it seems that's the problem. If I pass in $table and use a
lexical variable defined inside do_delete(), the problem goes away.
So, this is where my understanding of how triggers work lacks. For a
given session, each execution of a trigger isn't completely
independent?

--
Brandon