C++ client libs - Mailing list pgsql-hackers

>I was wondering if anyone could offer me some pointers in extending the
>C++ classes used for client applications?  I'm interested in developing a
>set of C++ classes which will interact directly with the postgres
>back-end with the following enhancements to the current implementation:

>These are preliminary musings and definitely open to change.

>1) Implement connections as a stream object. e.g. 
>   db = new pg_database(char * connection_params);
>   db << sql_string;

I wouldn't have thought of using the stream operators this way, but I
guess it sounds reasonable. One tricky bit, though, how do you distinguish
synchronous and asynchronous use this way? In the synchronous case, do you
expect some sort of return value from this process? Where do you get it 
from? In the asynchronous case, how do you prevent a new query being sent
down the socket while a previous one is still working away and
transmitting results?

>2) Implement results as a returned object from pg_database
>   result = db.exec();
>   result >> field1 >> field2 >> field3;
>   and
>   field = result["field"];
>   field = result[fieldnum];

What type is field? Is it always string, or can it be int, double, time_t
etc? And presumably you want to specify the row in there somewhere (maybe
it defaults to zero); or is field an array of some sort?

>3) Implement asynchronous calls to the back-end permitting multiple
>   queries to be executed concurrently

Implement async calls, yes, definitely a good thing to do. But this by
itself doesn't buy you multiple queries concurrently; for that you need
multiple connections to the database, which would also be worth doing in
this library.

BTW, for async calls, you would want to create some convenient way of
registering your interest in the socket connection, and some standard
methods that read the result from it. Presuming the normal use for this is
via a select-driven event loop, you want to be able to register the socket
with whatever code drives the select, and register a callback that looks
at the socket whenever select goes off. Given that there are umpteen dozen
implementations of a select-driven event loop, it will be a challenge
developing something that works nicely with all of them.

It'd also be good to find out where Chris Bitmead is up to with his work
on a streaming version of libpq, since that would be a bit tricky to
handle here, but buys you a lot of useful functionality and much more
efficient memory usage, so it would be worthwhile.

>4) Implement a standard set of exceptions which can be thrown 
>   ex. if connection to back-end is interrupted or cannot be established
>   within 30 seconds of the first attempt, throw.

Fair enough, but I'd suggest you make this an optional feature, since not
everyone wants to use exceptions. Make sure there's some way to switch
exceptions off (or better, some way to not switch exceptions on).

>5) I'm looking at making the libraries portable between FreeBSD, Solaris 
>   Linux and Win32.

>If anyone has suggestions/additions to this list it would be greatly
>appreciated!

I've developed something vaguely similar for our internal use, which
addresses some of the above (particularly async calls); unfortunately it's
heavily tied to other libraries we use in-house, so not of much use
generally. I did have a plan at the back of my mind to one of these days
produce a more independent version of our library, and go about persuading
folks here that we should contribute it to PostgreSQL, but if your effort
goes ahead successfully then that won't be necessary.

BTW, I'd urge you to keep the discussion public. The interfaces list might
be a good place, rather than hackers, but don't go hiding away in private
email or some other obscure place. A public discussion will get you useful
input from a much wider range of people. And it would make a welcome
change from the usual "Help! Help! MS Access has made all my fields
read-only!" and "Why doesn't the JDBC driver implement this?" questions on
the interfaces list :-).

>Cheers,
>
>Randy Jonasz


Tim Allen

--
-----------------------------------------------
Tim Allen          tim@proximity.com.au
Proximity Pty Ltd  http://www.proximity.com.au/ http://www4.tpg.com.au/users/rita_tim/