pg.ddx.io pgsql-interfaces@postgresql.org mailing list archive
help / color / mirror / Atom feedBUG in PgODBC found/fixed (win32)
2+ messages / 2 participants
[nested] [flat]
* BUG in PgODBC found/fixed (win32)
@ 1999-10-23 22:10 Sam O'Connor <Sam@OConnor.net>
1999-10-25 01:03 ` Re: [INTERFACES] BUG in PgODBC found/fixed (win32) Byron Nikolaidis <byron.nikolaidis@home.com>
0 siblings, 1 reply; 2+ messages in thread
From: Sam O'Connor @ 1999-10-23 22:10 UTC (permalink / raw)
To: pgsql-interfaces
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.patch
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;
+ }
}
}
}
* Re: [INTERFACES] BUG in PgODBC found/fixed (win32)
1999-10-23 22:10 BUG in PgODBC found/fixed (win32) Sam O'Connor <Sam@OConnor.net>
@ 1999-10-25 01:03 ` Byron Nikolaidis <byron.nikolaidis@home.com>
0 siblings, 0 replies; 2+ messages in thread
From: Byron Nikolaidis @ 1999-10-25 01:03 UTC (permalink / raw)
To: Sam O'Connor <Sam@OConnor.net>; +Cc: pgsql-interfaces
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;
> + }
> }
> }
> }
>
> ************
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~1999-10-25 01:03 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
1999-10-23 22:10 BUG in PgODBC found/fixed (win32) Sam O'Connor <Sam@OConnor.net>
1999-10-25 01:03 ` Byron Nikolaidis <byron.nikolaidis@home.com>
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