SOURCE 

>  -----Original Message-----
>  From: boost-bounces@[...].org
[mailto:boost-bounces@[...].org]
>  On Behalf Of Jonathan Wakely
 
>  I haven't looked at all the code yet, but I like the interface and
what
>  I've seen so far - I'm definitely interested in this library,

Thanks!

>  
>  > 2) Boost.Database.Postgresql - an implementation of the above
interface
>  > for postgresql
>  
>  I have an implementation of your database library for MySQL.  It's on
my
>  hard drive at home and I'm broadband-less right now so if anyone wants
>  to see it let me know and I'll dial up tonight.  It was very easy to
>  adapt to use the MySQL API.

I'd like to see it when you get a chance.

>  postgresql/connect.cpp accidentally uses the <:: trigraph in the
>  typedefs at the top of the file.  You need a space before the template
>  args to avoid that.

Maybe I should put the files in the sandbox?  Did you happen to make
Boost.Jam files to compile the test?

>  How do you handle NULL values?  the postgresql::row_set_imp::get()
>  function
>  doesn't seem to account for NULL, which would crash strlen(), atof()
etc.

I was thinking about this some more.  Long ago, where I work we had bad
experiences with once working programs crashing when they tried to read
null fields (via DAO) when we really just wanted default values (0s and
empty strings).  Ever since then when I've written a wrapper for a
database library I've always provided automatic conversion of nulls to
default values.

Now that you've brought this up, however, I can see that not only are
nulls important to some users, but that they will also be important for
the serialization library when serializing boost::optionals.  The method
I'm using now is not so good.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost