Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 25422 invoked from network); 10 Jun 2006 02:10:30 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 10 Jun 2006 02:10:30 -0000 Received: (qmail 70419 invoked by uid 500); 10 Jun 2006 02:10:30 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 70067 invoked by uid 500); 10 Jun 2006 02:10:29 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 70056 invoked by uid 99); 10 Jun 2006 02:10:28 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 09 Jun 2006 19:10:28 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [206.47.199.165] (HELO simmts7-srv.bellnexxia.net) (206.47.199.165) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 09 Jun 2006 19:10:27 -0700 Received: from [192.168.0.103] ([65.94.54.100]) by simmts7-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20060610021005.YIQP16677.simmts7-srv.bellnexxia.net@[192.168.0.103]>; Fri, 9 Jun 2006 22:10:05 -0400 Message-ID: <448A2A32.6010200@pearsoncmg.com> Date: Fri, 09 Jun 2006 22:10:58 -0400 From: Chris Darroch Organization: Pearson CTG/CMG User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060423 X-Accept-Language: en-ca, en-us MIME-Version: 1.0 To: dev@apr.apache.org Subject: [PATCH] apr_dbd_oracle.c query/select fixes #37664 X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Hi -- Maybe someone with APR commit access (Nick, Bojan?) could review the patch I've attached to PR 37664 and commit it to trunk; it has a variety of fixes and cleanups for apr_dbd_oracle.c. It's been a while since I touched that PR but I'm sort of holding it open for future Oracle driver patches; let me know if you want to close it. Thanks! From the PR notes: This patch file contains a variety of fixes and cleanups, mostly related to the prepare function and the various query and select functions. The pvquery and pvselect functions were looking for true int and double arguments in the va_list args. This is not how other drivers function; for example, the pgsql and sqlite3 drivers assume all va_list arguments as strings. This is in keeping with the pquery and pselect functions too. So, make the Oracle driver do the same. The OCIStmtRelease() function should only be used if Oracle statement handles have been prepared with OCIStmtPrepare2(), which is only available in Oracle 9.2 and above. For now, stick with just OCIHandleFree() and put the stuff related to OCIStmtRelease() into unused #ifdef blocks in the freeStatement() and freeStatements() APR memory pool callback cleanup functions. Note that when OCIStmtRelease() is used in the future, OCIHandleFree() should not be used because OCIStmtRelease() will do that for you. The freeStatement() callback cleanup function should return apr_status_t to match the return value expected by apr_pool_cleanup_register() and friends. The freeStatement() callback cleanup function should also use a private Oracle error handle like the freeStatements() one (if and when it uses OCIStmtRelease() in the future). Otherwise, if an error occurs during the execution of dbd_oracle_query(), then the call to apr_pool_destroy() on the private pool causes freeStatement() to be called, which if it then encounters its own error, would then overwrite the previous error data in the Oracle handle. That in turn means the caller can't access the original error message that caused apr_dbd_query() to fail. In all #ifdef DEBUG blocks, never overwrite sql->status. Otherwise the debugging code changes the error values and messages output, which isn't really what you want debugging code to do; instead, it should be non-invasive. In dbd_oracle_prepare(), make sure to set stmt->nargs to 0 before counting arguments in the SQL query. Otherwise, if the caller passes a non-NULL statement pointer (i.e., a previously allocated apr_dbd_prepared_t structure), we miscalculate the number of expected arguments to p[v]query/select(). This usually causes a crash when the subsequent calls to p[v]query/select() are made. Finally, remove some non-functional BLOB/CLOB trial code from pvquery() and make it similar to the other three p[v]query/select() functions in this regard. Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B