d == dev@xxxxxxxxxxxx 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
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
