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

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