b == bmetcalf@xxxxxxxxxxxxxxxxxx writes:
b> d == dev@xxxxxxxxxxxx writes:
b> d> Brandon Metcalf wrote:
b> d> > Yep, it seems that's the problem. If I pass in $table and use a
b> d> > lexical variable defined inside do_delete(), the problem goes away.
b> d> > So, this is where my understanding of how triggers work lacks. For a
b> d> > given session, each execution of a trigger isn't completely
b> d> > independent?
b> d> Nothing to do with triggers - it's all to do with your Perl code.
b> I respectfully disagree because if I don't execute a DELETE on foo2 as
b> shown in my original email, the problem doesn't occur. Somewhere in
b> the trigger execution it's remembering the first table on which the
b> trigger fired. So, the information about foo2 is coming from
b> somewhere and it's in the Perl code. In other words, I performing two
That should read it's _not_ in the Perl code.
b> different DELETEs which cause two different invocations of the same
b> trigger.
b> d> #!/usr/bin/perl
b> d> sub foo {
b> d> my $x = shift;
b> d> print "foo x = $x\n";
b> d> bar();
b> d> return;
b> d> sub bar {
b> d> print "bar x = $x\n";
b> d> }
b> d> }
b> d> foo(1);
b> d> foo(2);
b> d> exit;
b> d> $ ./perl_example.pl
b> d> foo x = 1
b> d> bar x = 1
b> d> foo x = 2
b> d> bar x = 1
b> d> If you use warnings it'll tell you about it too with this example.
--
Brandon
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
