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

d == dev@archonet.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