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

d == dev@archonet.com writes:

 d> Brandon Metcalf wrote:
 d> > d == dev@archonet.com writes:
 d> >
 d> >  d> Brandon Metcalf wrote:
 d> >  d> > Yep, it seems that's the problem.  If I pass in $table and use a
 d> >  d> > lexical variable defined inside do_delete(), the problem goes away.
 d> >  d> > So, this is where my understanding of how triggers work lacks.  For a
 d> >  d> > given session, each execution of a trigger isn't completely
 d> >  d> > independent?
 d> >
 d> >  d> Nothing to do with triggers - it's all to do with your Perl code.
 d> >
 d> >
 d> > I respectfully disagree because if I don't execute a DELETE on foo2 as
 d> > shown in my original email, the problem doesn't occur.

 d> Of course not.

 d> >  Somewhere in
 d> > the trigger execution it's remembering the first table on which the
 d> > trigger fired.

 d> Yes. in your "sub do_delete" with it's local variable.

 d> > So, the information about foo2 is coming from
 d> > somewhere and it's in the Perl code.

 d> Yes, your local copy of $table in do_delete.

 d> > In other words, I performing two
 d> > different DELETEs which cause two different invocations of the same
 d> > trigger.

 d> You've written your code such that do_delete has a local copy of $table.
 d>   In fact, the way it actually works iirc is that when you exit the
 d> trigger function "my $table" goes out of scope and vanishes, but the
 d> "$table" in do_delete doesn't vanish and persists from call to call. You
 d> might call this a static variable in C terms.


OK.  I understand the Perl part of what is going on.  What I don't
understand is why $table in do_delete() hangs around.  It seems this
is more a characteristic of how triggers work in pgsql.  At any rate,
I appreciate the input since it provides me with a fix.


 d> >  d> #!/usr/bin/perl
 d> >
 d> >  d> sub foo {
 d> >  d>     my $x = shift;
 d> >  d>     print "foo x = $x\n";
 d> >  d>     bar();
 d> >  d>     return;
 d> >
 d> >  d>     sub bar {
 d> >  d>         print "bar x = $x\n";
 d> >  d>     }
 d> >  d> }
 d> >
 d> >  d> foo(1);
 d> >  d> foo(2);
 d> >  d> exit;

 d> This code mirrors _exactly_ what is happening with your trigger. On the
 d> first call to foo $x is set to 1, on the second it's set to 2. That
 d> doesn't affect "sub bar" though because its copy of $x is still the one
 d> from the first call.

 d> Maybe the following makes it clearer:
 d> #!/usr/bin/perl

 d> sub foo {
 d>         my $x = shift;
 d>         print "foo x = $x, ";
 d>         bar();
 d>         return;

 d>         sub bar {
 d>                 print "bar x = $x\n";
 d>                 $x--;
 d>         }
 d> }

 d> for my $i (1..5) { foo($i); }
 d> exit;

 d> $ ./perl_example.pl
 d> foo x = 1, bar x = 1
 d> foo x = 2, bar x = 0
 d> foo x = 3, bar x = -1
 d> foo x = 4, bar x = -2
 d> foo x = 5, bar x = -3

 d> The two $x variables go their separate ways and the one in "bar" doesn't
 d> go out of scope at the end of the function.



--
Brandon