Received: from mail.rdc1.md.home.com (imail@ha1.rdc1.md.home.com [24.2.2.66]) by hub.org (8.9.3/8.9.3) with ESMTP id VAA39699 for ; Sun, 24 Oct 1999 21:13:11 -0400 (EDT) (envelope-from byron.nikolaidis@home.com) Received: from home.com ([24.4.141.52]) by mail.rdc1.md.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <19991025011309.YVD18396.mail.rdc1.md.home.com@home.com>; Sun, 24 Oct 1999 18:13:09 -0700 Message-ID: <3813AC47.81F5F5C5@home.com> Date: Sun, 24 Oct 1999 21:03:03 -0400 From: Byron Nikolaidis Organization: @Home Network X-Mailer: Mozilla 4.5 [en]C-AtHome0405 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Sam O'Connor" CC: pgsql-interfaces@postgreSQL.org Subject: Re: [INTERFACES] BUG in PgODBC found/fixed (win32) References: <38123272.955C19B9@OConnor.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sam, Good job! I'd forgot about that hack ;) I put it in the cvs source tree and it will be in my next build. Byron Sam O'Connor wrote: > > The lo id is currently stored in the parameter EXEC_buffer pointer > with a cast, and is pulled out again later when it is needed. > Bit of a hack but it works. > Later on if EXEC_buffer is not NULL it is freed. Opps. > The fix is just to check for type SQL_LONGVARBINARY before > doing the deallocation. > > I'm not sure who the current maintainer is, I've just been happily using > the stuff recently without having to do any work on it. Yey :) > Should I just be putting fixes like this straight into CVS? > If so where can I get access. > > - Sam > > BTW. Is anyone else using postgres large objects through ODBC in > windows? > > Here are some diffs: > > diff -c -r pgodbc_vendor/bind.c pgodbc/bind.c > *** pgodbc_vendor/bind.c Fri Jan 08 10:32:46 1999 > --- pgodbc/bind.c Sat Oct 23 13:08:50 1999 > *************** > *** 123,131 **** > stmt->parameters[ipar].EXEC_used = NULL; > } > > ! if (stmt->parameters[ipar].EXEC_buffer) { > ! free(stmt->parameters[ipar].EXEC_buffer); > stmt->parameters[ipar].EXEC_buffer = NULL; > } > > /* Data at exec macro only valid for C char/binary data */ > --- 123,135 ---- > stmt->parameters[ipar].EXEC_used = NULL; > } > > ! if ( stmt->parameters[ipar].SQLType == SQL_LONGVARBINARY) { > stmt->parameters[ipar].EXEC_buffer = NULL; > + } else { > + if (stmt->parameters[ipar].EXEC_buffer) { > + free(stmt->parameters[ipar].EXEC_buffer); > + stmt->parameters[ipar].EXEC_buffer = NULL; > + } > } > > /* Data at exec macro only valid for C char/binary data */ > diff -c -r pgodbc_vendor/statement.c pgodbc/statement.c > *** pgodbc_vendor/statement.c Thu Sep 02 22:08:04 1999 > --- pgodbc/statement.c Sat Oct 23 13:07:24 1999 > *************** > *** 326,334 **** > self->parameters[i].EXEC_used = NULL; > } > > ! if (self->parameters[i].EXEC_buffer) { > ! free(self->parameters[i].EXEC_buffer); > self->parameters[i].EXEC_buffer = NULL; > } > } > } > --- 326,338 ---- > self->parameters[i].EXEC_used = NULL; > } > > ! if ( self->parameters[i].SQLType == SQL_LONGVARBINARY) { > self->parameters[i].EXEC_buffer = NULL; > + } else { > + if (self->parameters[i].EXEC_buffer) { > + free(self->parameters[i].EXEC_buffer); > + self->parameters[i].EXEC_buffer = NULL; > + } > } > } > } > > ************