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

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

d> Brandon Metcalf wrote:
d> > d == dev(at)archonet(dot)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