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

d == dev@archonet.com writes:

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

 d> Because it will persist until either:
 d> 1. "sub do_delete" expires
 d> 2. the whole perl interpreter expires (which then implies #1)

 d> Your trigger function will be "compiled"* just before it is first called
 d> and will then exist until #2 above happens (when you disconnect). Since
 d> your trigger function exists, that implies do_delete continues to exist
 d> which means its version of $table continues to exist. It really is
 d> exactly like that example script I attached, where the "exit" equals
 d> database end-of-session.

OK, that makes sense.

 d> * ok, perl is technically interpreted, except of course it isn't really,
 d> and I don't know what a better term than compiled would be.

No, you're right.  It is compiled before being executed, but not in
the sense that C code is compiled.


--
Brandon