libdbi-devel — Discussion about development of the core library and DBD interface

Re: [libdbi-devel] libdbi+mysql4

[Cami <ca...@mw...>]

Markus Hoenicka wrote:
> Hi Cami,
> 
> I've spent the last week or so to add support for MySQL4.1 and later
> features to libdbi, most notably the character encoding
> support. Please have a look at the current cvs version. I've also
> fixed the debian directories, so if you happen to use Debian you can
> build and test drive packages. I'm testing libdbi against MySQL 4.1
> and so far did not bump into problems. If you would like to see a
> particular feature added or a particular problem fixed, please let us
> know.

I sent a mail a few months ago. libdbi didnt work with mysql >= 4.0..
Every time an error occured, libdbi would cause a crash.

Any timelines for a new stable release?

Cami

[libdbi-devel] libdbi+mysql4

[Markus H. <mar...@mh...>]

Hi Cami,

I've spent the last week or so to add support for MySQL4.1 and later
features to libdbi, most notably the character encoding
support. Please have a look at the current cvs version. I've also
fixed the debian directories, so if you happen to use Debian you can
build and test drive packages. I'm testing libdbi against MySQL 4.1
and so far did not bump into problems. If you would like to see a
particular feature added or a particular problem fixed, please let us
know.

regards,
Markus

Cami writes:
 > Hi All,
 > 
 > Is anyone planning on including support for MySQL 4.x
 > for libdbi?
 > 

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

[libdbi-devel] libdbi+mysql4

[Cami <ca...@mw...>]

Hi All,

Is anyone planning on including support for MySQL 4.x
for libdbi?

Cami

[libdbi-devel] [PATCH] Memory Leak Fix

[Markus H. <mar...@mh...>]

Hi James,

studied, applied, tested, checked in :-)

thanks again
Markus

James Sella writes:
 > The attached patch fixes a memory leak within libdbi. The memory leak 
 > can be seen if you perform a query, seek and then free the result set.
 > 

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

Re: [libdbi-devel] [PATCH] Memory Leak

[Markus H. <mar...@mh...>]

Hi James,

thanks for bringing this up again. I have picked up the loose ends of libdbi
only recently, and I was just about to start going backwards through the mails
to hunt for even more loose ends. I vaguely remembered your post, so I would
have eventually come across it. I'll take care of your patch later tonight.

Thanks
Markus

James Sella <se...@di...> was heard to say:

> Sorry for the repeat post, but I want to make sure this doesn't slip
> though the cracks (it hasn't been applied to the repository).
>


-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

[libdbi-devel] [PATCH] Memory Leak

[James S. <se...@di...>]

Sorry for the repeat post, but I want to make sure this doesn't slip 
though the cracks (it hasn't been applied to the repository).

-Jim

-------- Original Message --------
Subject: [libdbi-devel] [PATCH] Memory Leak Fix
Date: Tue, 22 Mar 2005 00:39:34 -0700
From: James Sella <se...@di...>
To: lib...@li...

The attached patch fixes a memory leak within libdbi. The memory leak
can be seen if you perform a query, seek and then free the result set.

It can be applied as follows, within the libdbi directory (newest cvs
checkout):

    cd libdbi
    patch -p1 < libdbi-leak-fix.patch

The function call _dbd_row_allocate() within src/dbd_helper.c, allocate
memory for row->field_flags. The function call _free_result_rows()
within src/dbi_result.c should release it, however doesn't.

[src/dbd_helper.c]
dbi_row_t *_dbd_row_allocate(unsigned short numfields) {
     dbi_row_t *row = malloc(sizeof(dbi_row_t));
     if (!row) return NULL;
     row->field_values = calloc(numfields, sizeof(dbi_data_t));
     row->field_sizes = calloc(numfields, sizeof(unsigned long long));
     /* Allocated below */
     row->field_flags = calloc(numfields, sizeof(unsigned char));
     return row;
}

[src/dbi_result.c]
static void _free_result_rows(dbi_result_t *result) {
     unsigned long long rowidx = 0;
     unsigned short fieldidx = 0;

     for (rowidx = 0; rowidx <= result->numrows_matched; rowidx++) {
        if (!result->rows[rowidx]) continue;

        for (fieldidx = 0; fieldidx < result->numfields; fieldidx++) {
           if (((result->field_types[fieldidx] == DBI_TYPE_STRING) ||
(result->field_types[fieldidx] == DBI_TYPE_BINARY)) &&
result->rows[rowidx]->field_values[fieldidx].d_string) {
              free(result->rows[rowidx]->field_values[fieldidx].d_string);
           }
        }

        free(result->rows[rowidx]->field_values);
        free(result->rows[rowidx]->field_sizes);
        /* Should be free'd here. */
        free(result->rows[rowidx]);
     }

     free(result->rows);
}

-Jim

[libdbi-devel] libdbi 0.7.2 patch

[Markus H. <mar...@mh...>]

Hi Daniel,

thanks for tracking this down, and even more thanks for the
patch. I've checked in the fix.

regards,
Markus

Daniel O'Neill writes:
 > I've found a silly little bug in dbd_helper.c, which on 32-bit arch looks 
 > harmless, but on AMD64 it croaks rather badly.
 > 
 > Basically, it's an allocation to result->field_attribs (array of pointers to 
 > unsigned integers) which is called as such:
 > 
 > result->field_attribs = calloc(numfields, sizeof(unsigned int));
 > 
 > which, since it's an array of Pointers, which on AMD64 is 48bit, this 
 > under-allocates, and should actually be:
 > 
 > result->field_attribs = calloc(numfields, sizeof(unsigned int *));
 > 
 > Well, a simple one, but here's a patch anyway
 > 

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

[libdbi-devel] libdbi 0.7.2 patch

[Daniel O'N. <do...@th...>]

I've found a silly little bug in dbd_helper.c, which on 32-bit arch looks 
harmless, but on AMD64 it croaks rather badly.

Basically, it's an allocation to result->field_attribs (array of pointers to 
unsigned integers) which is called as such:

result->field_attribs = calloc(numfields, sizeof(unsigned int));

which, since it's an array of Pointers, which on AMD64 is 48bit, this 
under-allocates, and should actually be:

result->field_attribs = calloc(numfields, sizeof(unsigned int *));

Well, a simple one, but here's a patch anyway

Regards,

Daniel F. O'Neill, Ph.D
The Lodging Company
http://skihills.com/

United Kingdom, Germany, & France: 00-800-7542-2754
Australia: 0011-800-7542-2754
Mexico: 001-800-514-9977
All other areas: 1-250-979-3939
Fax: 1-250-868-6752

Direct Extension 256
OpenPGP Public Key ID: 0x9E3CA120

[libdbi-devel] Debian packages broke?

[Markus H. <mar...@mh...>]

FYI, I've filed a Debian bug report: #309313

regards,
Markus

Markus Hoenicka writes:
 > Hi,
 > 
 > I've had several reports about problems with the packaged versions of
 > libdbi and libdbi-drivers on Debian lately, see these threads for
 > further information:
 > 
 > http://sourceforge.net/mailarchive/forum.php?thread_id=7258378&forum_id=1798
 > 
 > http://sourceforge.net/mailarchive/forum.php?thread_id=7217315&forum_id=1099
 > 
 > Taken together, it seems like the MySQL driver malfunctions and
 > sometimes causes segfaults. libdbi itself and at least the SQLite driver
 > appear to work ok.
 > 
 > The first thread also indicates that it is not possible to build
 > Debian packages on a current Debian system.
 > 
 > Can anyone (preferably the package maintainer :-) comment on this?
 > Both as a developer and as a user I'd like to see the packages fixed.
 > 
 > regards,
 > Markus


-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

[libdbi-devel] Debian packages broke?

[Markus H. <mar...@mh...>]

Hi,

I've had several reports about problems with the packaged versions of
libdbi and libdbi-drivers on Debian lately, see these threads for
further information:

http://sourceforge.net/mailarchive/forum.php?thread_id=7258378&forum_id=1798

http://sourceforge.net/mailarchive/forum.php?thread_id=7217315&forum_id=1099

Taken together, it seems like the MySQL driver malfunctions and
sometimes causes segfaults. libdbi itself and at least the SQLite driver
appear to work ok.

The first thread also indicates that it is not possible to build
Debian packages on a current Debian system.

Can anyone (preferably the package maintainer :-) comment on this?
Both as a developer and as a user I'd like to see the packages fixed.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

Re: [libdbi-devel] (no subject)

[Christian M. S. <cm...@ce...>]

Hello hello,

On Monday 09 May 2005 23.06, Markus Hoenicka wrote:
> Hi all,
>
> I'd like to see how many of my fellow developers are still active in
> the project. Once again I've got to a point where my pet project
> (RefDB, http://refdb.sourceforge.net) needs some additional
> functionality in terms of SQL databases. In fact, the current version
> requires the libdbi-drivers and libdbi CVS versions in order to run
> properly with all supported database engines, a fact that package
> maintainers do not exactly appreciate.

Im still here. Allthough in submarine mode because I live with a rather strict 
time schedule at the moment. 
But I will come to surface and fix new functionality and/or bugs in the 
drivers im maintaining when nessisary. 

There are other issues that talk for a new release. For instance the fix made 
some time ago that gives the possibility to find out if a column value is 
NULL or just '' is also such a big show stopper that it qualifies for a new 
release. 


> I've noticed in the CVS log that mainly Christian made some fixes in
> the past. He has also added new drivers. I've added a sqlite3 driver
> myself, which supports libsqlite3 (incompatible with the older 2.x
> versions). I'd like to see all this new stuff wrapped up in released
> versions.
>
> Is anyone willing to help creating another maintenance release?

I am,  Having a "uptodate" version of libdbi out in the streets will help me 
alot as im using libdbi in other projects. 


>
> In terms of bug fixing I'm especially interested in one issue which is
> currently above my head. MySQL 4.1 and later has a quite confusing
> support for character encodings, collations and whatever. What makes
> it most confusing to me is that there are database encodings, which
> need not be identical with connection encodings. Has anyone ever
> looked into this? All that I can say is that RefDB using MySQL 4.1 as
> the database engine does not appear to do the right thing, most likely
> because mysql_character_set_name() in the mysql driver does not return
> what we expect. I'll look into this more closely but I wanted to hear
> first whether someone else is working on this.


I havnt looked at how MySQL handles it, but I guess its the same problem as 
with the Oracle driver. Diffrent columns in a result set can be of diffrent 
character sets. Depending on several resons including the queries.


Regards, 

-- 
Christian M. Stamgren |  Head of development
Direct: +46 (0)8-410 446 01 | Mobile: +46 (0)708-50 74 01
E-mail: cm...@ce...
Internet: www.cention.se
 
Cention AB | PO Box 3326 | SE-103 66 Stockholm | Sweden
Visiting address: Birger Jarlsgatan 20 | SE-114 34 Stockholm
Phone: +46 (0)8-410 446 00 | Fax: +46 (0)8-656 49 00

[libdbi-devel] (no subject)

[Markus H. <mar...@mh...>]

Hi all,

I'd like to see how many of my fellow developers are still active in
the project. Once again I've got to a point where my pet project
(RefDB, http://refdb.sourceforge.net) needs some additional
functionality in terms of SQL databases. In fact, the current version
requires the libdbi-drivers and libdbi CVS versions in order to run
properly with all supported database engines, a fact that package
maintainers do not exactly appreciate.

I've noticed in the CVS log that mainly Christian made some fixes in
the past. He has also added new drivers. I've added a sqlite3 driver
myself, which supports libsqlite3 (incompatible with the older 2.x
versions). I'd like to see all this new stuff wrapped up in released
versions.

Is anyone willing to help creating another maintenance release?

In terms of bug fixing I'm especially interested in one issue which is
currently above my head. MySQL 4.1 and later has a quite confusing
support for character encodings, collations and whatever. What makes
it most confusing to me is that there are database encodings, which
need not be identical with connection encodings. Has anyone ever
looked into this? All that I can say is that RefDB using MySQL 4.1 as
the database engine does not appear to do the right thing, most likely
because mysql_character_set_name() in the mysql driver does not return
what we expect. I'll look into this more closely but I wanted to hear
first whether someone else is working on this.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

[libdbi-devel] [PATCH] Memory Leak Fix

[James S. <se...@di...>]

The attached patch fixes a memory leak within libdbi. The memory leak 
can be seen if you perform a query, seek and then free the result set.

It can be applied as follows, within the libdbi directory (newest cvs 
checkout):

   cd libdbi
   patch -p1 < libdbi-leak-fix.patch

The function call _dbd_row_allocate() within src/dbd_helper.c, allocate 
memory for row->field_flags. The function call _free_result_rows() 
within src/dbi_result.c should release it, however doesn't.

[src/dbd_helper.c]
dbi_row_t *_dbd_row_allocate(unsigned short numfields) {
    dbi_row_t *row = malloc(sizeof(dbi_row_t));
    if (!row) return NULL;
    row->field_values = calloc(numfields, sizeof(dbi_data_t));
    row->field_sizes = calloc(numfields, sizeof(unsigned long long));
    /* Allocated below */
    row->field_flags = calloc(numfields, sizeof(unsigned char));
    return row;
}

[src/dbi_result.c]
static void _free_result_rows(dbi_result_t *result) {
    unsigned long long rowidx = 0;
    unsigned short fieldidx = 0;

    for (rowidx = 0; rowidx <= result->numrows_matched; rowidx++) {
       if (!result->rows[rowidx]) continue;

       for (fieldidx = 0; fieldidx < result->numfields; fieldidx++) {
          if (((result->field_types[fieldidx] == DBI_TYPE_STRING) || 
(result->field_types[fieldidx] == DBI_TYPE_BINARY)) && 
result->rows[rowidx]->field_values[fieldidx].d_string) {
             free(result->rows[rowidx]->field_values[fieldidx].d_string);
          }
       }

       free(result->rows[rowidx]->field_values);
       free(result->rows[rowidx]->field_sizes);
       /* Should be free'd here. */
       free(result->rows[rowidx]);
    }

    free(result->rows);
}

-Jim

[libdbi-devel] specfile issues

[John S. <jo...@sm...>]

I have found a couple of minor problems with the specfiles that are
included in the libdbi packages.

1. libdbi-0.7.1, libdbi-0.7.2
The file "libdbi.spec.in" includes the file:

README.drivers

This file is not included in the distributions.


2. libdbi-drivers-0.7.1
The file "libdbi.spec.in" does not include the documentation files:

drivers/mysql/dbd_mysql.pdf
drivers/mysql/dbd_mysql/index.html
drivers/mysql/dbd_mysql/x131.html
drivers/mysql/dbd_mysql/x39.html
drivers/mysql/dbd_mysql/c36.html
drivers/mysql/dbd_mysql/c32.html
drivers/mysql/dbd_mysql/c128.html
drivers/mysql/dbd_mysql/f21.html
drivers/mysql/dbd_mysql/c90.html
drivers/mysql/dbd_mysql/x53.html

drivers/pgsql/dbd_pgsql.pdf
drivers/pgsql/dbd_pgsql/specific.html
drivers/pgsql/dbd_pgsql/install.html
drivers/pgsql/dbd_pgsql/index.html
drivers/pgsql/dbd_pgsql/install-build.html
drivers/pgsql/dbd_pgsql/f27.html
drivers/pgsql/dbd_pgsql/copying-fdl.html
drivers/pgsql/dbd_pgsql/options.html
drivers/pgsql/dbd_pgsql/install-prereq.html
drivers/pgsql/dbd_pgsql/intro.html


Cheers,

John

[libdbi-devel] Problem in escaping function dbd_quote_string()

[Cristian P. <pa...@ti...>]

Hi,

I found a problem with the escaping function dbd_quote_string() of the mysql
driver. When this function call the mysql api  mysql_escape_string() it pass
the lenght of the original string as calculated with the strlen() C api.

int dbd_quote_string(dbi_driver_t *driver, const char *orig, char *dest) {
 /* foo's -> 'foo\'s' */
 unsigned int len;
 strcpy(dest, "'");
 len = mysql_escape_string(dest+1, orig,      strlen(orig)  );   <==========
 strcat(dest, "'");
 return len+2;
}

This compromise the ability to escape binary string that can contain '\0'
characters before the end.

I suggest to change the dbd_quote string() in order to accept the length of
the string as parameter. The same for the abstract function
dbi_driver_quote_string_copy() and dbi_driver_quote_string() that call the
driver function.

Otherwise we could add  new functions with the '_binary_' word that accept
the lenght of the buffer:

int dbi_driver_quote_binary_string_copy(dbi_driver Driver, const char *orig,
int orig_len, char **newquoted)
int dbi_driver_quote_binary_string(dbi_driver Driver, char **orig, int
orig_len)

and for the driver:

int dbd_quote_binary_string(dbi_driver_t *driver, const char *orig, int
orig_len char *dest)

Bye
Cristian

[libdbi-devel] libdbi homepage file permissions

[Markus H. <mar...@mh...>]

Hi,

I've just uploaded a new Cygwin binary package to the download area of the
libdbi homepage. I'd like to move the old version to /old but I don't have the
permissions. David, could you please run a g+w on these files? This should
allow me to move them around.

thanks,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

[libdbi-devel] Incorrect Generic Example Program

[Cami <ca...@mw...>]

Hi All,

Just for clarities sake,

..
     dbi_conn_connect(conn);
result = dbi_conn_query(conn, "SELECT id, name FROM coders "
                               "WHERE hours_of_sleep > %0.2f", threshold);
..

should be:

..
     dbi_conn_connect(conn);
result = dbi_conn_queryf(conn, "SELECT id, name FROM coders "
                               "WHERE hours_of_sleep > %0.2f", threshold);
..


otherwise it wont compile.

Cami

[libdbi-devel] new function proposal

[Cristian P. <cp...@se...>]

Hi,

I think that would be useful having a new function in libdbi library
that can make the user get the current error handler (with the user
argument also).

If so, I can save the current handler, set a new handler and, after some
stuff, restore the older handler.

Bye,
Cristian

Re: [libdbi-devel] About libdbi null handling patch.

[David P. <da...@ne...>]

On Mon, 23 Aug 2004 10:23:35 +0000, m.e...@ls... wrote:

> I agree with Christian and think it would be good if this could be fixed
> somehow.

I committed a fix (untested) in CVS late last night. Apparently the CVS mailer
is still broken, I'll see what's up with that. I made a couple small changes:

- changed the flag field to unsigned char for now to reduce memory overhead
  until we have more than 8 flags to set
- made a couple generic flag getting/setting helper functions so that other
  future flags can use the same interface

Once everything looks good, I'll take a look at the postgresql driver.

David

--
David Parker <da...@ne...>
Neon Goat Productions
http://www.neongoat.com

[libdbi-devel] Re: About libdbi null handling patch.

[David P. <da...@ne...>]

On Sun, 22 Aug 2004 21:04:38 +0200, Christian Stamgren wrote:

> I sent a patch to this list making libdbi handle columns with NULL values 
> about a month ago. With the patch there was a question if anyone with cvs 
> commit rights could commit this patch.
> 
> I haven't recieved any kind of answer from the libdbi maintainers at all. 
> 
> Can we have this patch commited or have some feedback on how the problem 
> should be solved in libdbi, so that I can try to make a patch more suitable 
> for libdbi.
> 
> I really want to see this problem fixed and feel that its almost big enough 
> for a new release, so please advice.

Sorry about the recent silence, I've been pretty busy with work and
travelling. Please keep reminding me in cases like this when I forget to do
something important ;) I'll commit to CVS tomorrow or Wednesday and maybe we
can try to make a release this weekend or sometime soon. I thought you had CVS
access but I guess not... just added you in case I disappear for too long
again. Thanks for taking the time to fix this bug.

David

--
David Parker <da...@ne...>
Neon Goat Productions
http://www.neongoat.com

Re: [libdbi-devel] About libdbi null handling patch.

[<m.e...@ls...>]

I agree with Christian and think it would be good if this could be fixed
somehow.

On Sun, 2004-08-22 at 19:04, Christian Stamgren wrote:
> Hello list, 
> 
> I sent a patch to this list making libdbi handle columns with NULL values 
> about a month ago. With the patch there was a question if anyone with cvs 
> commit rights could commit this patch.
> 
> I haven't recieved any kind of answer from the libdbi maintainers at all. 
> 
> Can we have this patch commited or have some feedback on how the problem 
> should be solved in libdbi, so that I can try to make a patch more suitable 
> for libdbi.
> 
> I really want to see this problem fixed and feel that its almost big enough 
> for a new release, so please advice.
> 
> 
> Best Regards, 
> 
> Christian
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> libdbi-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libdbi-devel
> 

[libdbi-devel] About libdbi null handling patch.

[Christian S. <cm...@ce...>]

Hello list, 

I sent a patch to this list making libdbi handle columns with NULL values 
about a month ago. With the patch there was a question if anyone with cvs 
commit rights could commit this patch.

I haven't recieved any kind of answer from the libdbi maintainers at all. 

Can we have this patch commited or have some feedback on how the problem 
should be solved in libdbi, so that I can try to make a patch more suitable 
for libdbi.

I really want to see this problem fixed and feel that its almost big enough 
for a new release, so please advice.


Best Regards, 

Christian

Re: [libdbi-devel] [PATCH] Make libdbi handle NULL values in a correct way again.

[Christian S. <chr...@ce...>]

Hmm, Hmm,

There was an error with my previous patch, I forgot to free the newly created 
flags variable. 

Attached is a new patch which also free'es the allocated memory....

Sorry about that, 

//Christian

On Friday 30 July 2004 16.10, Christian Stamgren wrote:
> Hi list,
>
> I have beem fiddling with some code to make handling of NULL values
> correct. I have created a flags variable inside dbi_row_t struct that is a
> bitfield that can be used for other meta-data as well, if we find something
> in the future .....
>
> I'm attaching patches for libdbi:
> I also attach a patch with a fix for my firebird driver as a reference
> case. tgt.c is a test program to test that the patch creates the wanted
> behaviour.
>
>
> If this is something that the libdbi project managers like, could someone
> please apply this patch agains libdbi cvs so that we can start the update
> of the libdbi-drivers.
>
>
>
> All the best,
>
> //Christian

[libdbi-devel] [PATCH] Make libdbi handle NULL values in a correct way again.

[Christian S. <cm...@ce...>]

Hi list,

I have beem fiddling with some code to make handling of NULL values correct. 
I have created a flags variable inside dbi_row_t struct that is a bitfield 
that can be used for other meta-data as well, if we find something in the 
future ..... 

I'm attaching patches for libdbi: 
I also attach a patch with a fix for my firebird driver as a reference case.
tgt.c is a test program to test that the patch creates the wanted behaviour. 


If this is something that the libdbi project managers like, could someone 
please apply this patch agains libdbi cvs so that we can start the update of 
the libdbi-drivers.



All the best, 

//Christian

[libdbi-devel] Re: [libdbi-users] stupid question about nulls

[Christian S. <chr...@ce...>]

Hmm yes, it was something like that I haved in mind .... 

But you are right. The unsigned'ness doesn't make this idea kosher. I didn't 
see that coming, my bad.
I guess it was when the unsigned'ness of  field_sizes got in, the problem  
with distinguish NULL fields got to the surface.

The right way to fix this problem might accually be to add an extra variable 
in dbi_row_t. And use that in dbi_result_field_isnull() to track down if a 
field is null or not.
That variable could be make into a bitfield in case there is some more 
meta-data that could be added to a column in the future. The drivers could 
then bitwise adding on values define in libdbi. say DBI_FIELD_ISNULL and 
more....


regards, 

//Christian 

On Friday 30 July 2004 11.52, m.e...@ls... wrote:
> Like this? This seems to work for me, but I find it vaguely troubling
> that the field size, which is an unsigned long long, is meant to be
> negative...
>
> dbd_pgsql.c.patch:
> 512a513
>
> >                       row->field_sizes[curfield] = -1;
>
> dbi_result.c.patch:
> 334a335,344
>
> > unsigned short dbi_result_isnull(dbi_result Result, const char*
>
> fieldname) {
>
> >       unsigned long long size = dbi_result_get_field_size(Result,
>
> fieldname);
>
> >       return (size == -1) ? 1 : 0;
> > }
> >
> > unsigned short dbi_result_isnull_idx(dbi_result Result, unsigned short
>
> idx) {
>
> >       unsigned long long size = dbi_result_get_field_size_idx(Result,
>
> idx);
>
> >       return (size == -1) ? 1 : 0;
> > }
>
> On Thu, 2004-07-29 at 17:43, Christian Stamgren wrote:
> > Hello again,
> >
> > Guess you are using the function
> > dbi_result_get_field_length( )   which today return size-1 for some
> > reason.
> >
> > You could use:
> > dbi_result_get_field_size( )  which returns the accual value.
> >
> > But I guess these functions would need to be tweaked to fit in with this
> > new behaviour.
> > The right (clean) way  of doing things would be to implement
> > dbi_result_field_isnull() or simular to check if a field is null.
> > That way we could change the internals of libdbi without changing all
> > applications that was hacked to check if size was -1. It will also make
> > it more obvious what happens.
> >
> > Regards,
> >
> > //Christian
> >
> > On Thursday 29 July 2004 15.14, m.e...@ls... wrote:
> > > Thanks Christian! I didn't even think of looking at the length...
> > >
> > > I only have pqsql, but it looks as if for this one at least the length
> > > is always 0 except for strings, where it is equal to the length of the
> > > string (as you say it does not seem to implement what's in the
> > > comment).
> > >
> > > I tried implementing your suggestion myself in dbd_pgsql.c, and got as
> > > far as
> > >
> > > 512a513
> > >
> > > >                       row->field_sizes[curfield] = -1;
> > >
> > > Unfortunately, now I get a length of -2 for NULLs???
> > >
> > > Maybe someone familiar with the driver could have a look at this? It
> > > would be neat to be able to distinguish between NULL, "" and 0...
> > >
> > > Max
> > >
> > > On Thu, 2004-07-29 at 12:41, Christian Stamgren wrote:
> > > > Hello.
> > > >
> > > > I belive this is a short comming of the libdbi-drivers as it looks
> > > > today.
> > > >
> > > > By reading dbi-dev.h you will find this row part of dbi_row_t
> > > > struct.:
> > > >
> > > > unsigned long long *field_sizes; /* NULL field = 0, string field =
> > > > len, anything else = -1 */
> > > >
> > > > But the drivers does not implemet it this way.
> > > >
> > > >
> > > > I'll suggest that we change it so that:
> > > > NULL field = -1, string field = len, anything else = 0
> > > >
> > > > That way we will have distinction between NULL and a string of 0
> > > > chars (which is not the same as NULL).
> > > >
> > > > It would then be easy to implement a couple of funtions like:
> > > >
> > > > dbi_result_field_isnull(result, "fieldname");
> > > > or
> > > > dbi_result_field_isnull_idx(result, 2);
> > > >
> > > >
> > > >
> > > > Regards,
> > > >
> > > > //Christian
> > > >
> > > > On Wednesday 28 July 2004 15.45, m.e...@ls... wrote:
> > > > > Hi,
> > > > >
> > > > > I have been running some queries that return NULLs at times (in
> > > > > fields that contain doubles).
> > > > >
> > > > > It looks as if you use dbi_result_get_double() you get 0 whenever
> > > > > the query returned a NULL.
> > > > >
> > > > > How can I distinguish between a NULL and 0? It looks like I might
> > > > > have missed something obvious here...
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Max
> > > > >
> > > > >
> > > > > -------------------------------------------------------
> > > > > This SF.Net email is sponsored by BEA Weblogic Workshop
> > > > > FREE Java Enterprise J2EE developer tools!
> > > > > Get your free copy of BEA WebLogic Workshop 8.1 today.
> > > > > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> > > > > _______________________________________________
> > > > > libdbi-users mailing list
> > > > > lib...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/libdbi-users