Question about moving a function from mysql.xs to dbdimp.c

Tim, For the longest time, there's been this annoying warning with the compile for DBD::mysql: cc -c -I/Library/Perl/5.8.1/darwin-thread-multi-2level/auto/DBI/ -I/usr/local/mysql/include -fno-omit-frame-pointer -DDBD_MYSQL_INSERT_ID_IS_GOOD -g -g -pipe -pipe -fno-common -DPERL_DARWIN

Re: Question about moving a function from mysql.xs to dbdimp.c

On Thu, 14 Apr 2005, Patrick Galbraith wrote: Tim, For the longest time, there's been this annoying warning with the compile for DBD::mysql: cc -c -I/Library/Perl/5.8.1/darwin-thread-multi-2level/auto/DBI/ -I/usr/local/mysql/include -fno-omit-frame-pointer

Re: Question about moving a function from mysql.xs to dbdimp.c

Rudy Lippan wrote: On Thu, 14 Apr 2005, Patrick Galbraith wrote: Tim, For the longest time, there's been this annoying warning with the compile for DBD::mysql: cc -c -I/Library/Perl/5.8.1/darwin-thread-multi-2level/auto/DBI/ -I/usr/local/mysql/include -fno-omit-frame-pointer

Memory leak in DBI using $sth-{NAME_..hash}

Hi, Using Perl 5.8.1 DBI 1.48 and DBD-DB2 0.78 on Linux, I'm seeing a memory leak looping through $sth-{NAME_lc}. The repro script and trace is below. Note that looping through the $dbh-prepare does not leak. Has someone else seen this before? or know where I can start looking? This looks like

Re: Memory leak in DBI using $sth-{NAME_..hash}

On Fri, 15 Apr 2005 12:54:48 -0400, DB2PERL [EMAIL PROTECTED] wrote: Hi, Using Perl 5.8.1 DBI 1.48 and DBD-DB2 0.78 on Linux, I'm seeing a memory leak looping through $sth-{NAME_lc}. The repro script and trace is below. Note that looping through the $dbh-prepare does not leak. It might

Re: Question about moving a function from mysql.xs to dbdimp.c

On Fri, 15 Apr 2005, Philip M. Gollucci wrote: #ifdef false void dbd_st_rows() {...} #endif newer compiles should also optimize: particularly gcc if (false) { } out Maybe I am missing something here, but what does optimizing out if blocks have to do with function

Re: Question about moving a function from mysql.xs to dbdimp.c

Rudy, What about how to deal with returning values (my_ulonglong) that are larger than the default defined value of dbd_st_rows from DBI (int) ? How do you ensure you can handle differently than the default rows? (like now how it's done with 'sprintf(buf, %llu)' ? It seems you need some sort

Memory leak in DBI using $sth-{NAME_..hash}

Please ignore my questions below. I have found the cause of the memory leak. Thanks. Regards, Michael __ Hi, Using Perl 5.8.1 DBI 1.48 and DBD-DB2 0.78 on Linux, I'm seeing a memory leak looping through $sth-{NAME_lc}. The repro script and trace is below. Note that looping

Re: Question about moving a function from mysql.xs to dbdimp.c

On Fri, 15 Apr 2005, Patrick Galbraith wrote: What about how to deal with returning values (my_ulonglong) that are larger than the default defined value of dbd_st_rows from DBI (int) ? Well, in Driver.xst (mysql.xst) dbd_st_rows returns void and sticks an SV on the stack, in this case the

Re: Question about moving a function from mysql.xs to dbdimp.c

On Fri, Apr 15, 2005 at 12:30:55PM -0700, Patrick Galbraith wrote: Rudy, What about how to deal with returning values (my_ulonglong) that are larger than the default defined value of dbd_st_rows from DBI (int) ? Actually an IV, which may be 64bit if perl is configured that way. How do

Re: patch for DBD::Pg README

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Perhaps this should be obvious, but it wasn't to me. I naively figured if I had an old DBD::Pg working and PostgreSQL working and I had everything listed in the README that I could install DBD::Pg 1.41. Not sure I've stated things correctly,