X-Original-To: pgsql-general@postgresql.org Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id E04634758F1 for ; Mon, 3 Feb 2003 14:31:11 -0500 (EST) Received: from biglumber.com (biglumber.com [207.228.252.42]) by postgresql.org (Postfix) with SMTP id F2ACE475A37 for ; Mon, 3 Feb 2003 14:30:11 -0500 (EST) Received: (qmail 22903 invoked from network); 3 Feb 2003 19:26:11 -0000 Received: from biglumber.com (HELO localhost) (207.228.252.42) by 0 with SMTP; 3 Feb 2003 19:26:11 -0000 From: greg@turnstep.com To: pgsql-general@postgresql.org Subject: Re: DBI driver and transactions X-PGP-Key: 2529 DF6A B8F7 9407 E944 45B4 BC9B 9067 1496 4AC8 In-Reply-To: Date: Mon, 3 Feb 2003 19:26:11 -0000 X-Mailer: JoyMail 1.36 Message-ID: X-Virus-Scanned: by AMaViS new-20020517 X-Archive-Number: 200302/137 X-Sequence-Number: 36891 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > So, the question is where's the error there? > > I might well completely have the wrong idea about perl and what happens with > lexically scoped variables but to me that says $sth gets destroyed because it > drops out of scope, even if the first exit from the function is taken. If not > then that says all lexically scoped variables remain allocated until explicitly > destroyed. So I could have a function creating and storing huge amounts of data > in 'my' variables and that data will still be stored, adding to the processes > memory footprint, until my process exits. That could be years. You first assumption is correct: if a statement handle goes out of scope, it no longer can be "Active" or "Inactive". What happens is this: when the disconnect method is called, it polls all the current statement handles to see if any of them are still have the Active flag set. If they do, it throws the error you see. However, destroying a statement handle (e.g. by leaving the scope in which its variable is declared) does not do any checking, and the Active flag is ignored. In other words: my $sth = $dbh->prepare("SELECT COUNT(*) FROM mansion WHERE who=? AND room=? AND item=?"); $sth->execute("Mustard","library","wrench"); $dbh->disconnect(); This throws the error. DBI is saying: Hey! You just went through all the trouble of making this query, don't you want to see all the results? { my $sth = $dbh->prepare("SELECT COUNT(*) FROM mansion WHERE who=? AND room=? AND item=?"); $sth->execute("Peacock","kitchen","candlestick"); } ## $sth is gone $dbh->disconnect(); No error is thrown in this case, as the variable $sth fails to exist at the end of the unnamed block, so the disconnect method has no way of knowing anything about the statement handle you created. In practice, finish() is not called very often, as you usually want to fetch everything you asked for. It's a nice short-circuit as in my first example, however, as it is more efficient than calling a fetch method if you know there is nothing there. - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200302031426 -----BEGIN PGP SIGNATURE----- Comment: http://www.turnstep.com/pgp.html iD8DBQE+PsKkvJuQZxSWSsgRArYYAKDDXvaJOerEOoHJoMtn+oxj71JzcACfSSV4 wGMsZL0nl3LUHW8Mrdn5Xu8= =RWel -----END PGP SIGNATURE-----