pg.ddx.io  pgsql-interfaces@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Sam O'Connor <Sam@OConnor.net>
To: pgsql-interfaces@postgreSQL.org
Subject: BUG in PgODBC found/fixed (win32)
Date: Sat, 23 Oct 1999 15:10:58 -0700
Message-ID: <38123272.955C19B9@OConnor.net> (raw)

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:

inline patch 1: pgodbc/bind.c, pgodbc/statement.c (+12/-4 lines) download inline-1.patchdiff -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; + } } } }

view thread (2+ messages)  latest in thread

Message-ID: <38123272.955C19B9@OConnor.net>
Permalink:  ../38123272.955C19B9@OConnor.net/
Also on:    postgresql.org/message-id/38123272.955C19B9@OConnor.net

 ·  · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-interfaces@postgresql.org
  Cc: Sam@OConnor.net
  Subject: Re: BUG in PgODBC found/fixed (win32)
  In-Reply-To: <38123272.955C19B9@OConnor.net>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox