>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/


Wed, 4 Oct 2000 12:38:35 +1100 (EST)
Tim Allen <tim@proximity.com.au>
C++ client libs
Tim Allen <tim@proximity.com.au> writes:
> 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.

100% agreement here.  pgsql-interfaces seems like the appropriate
discussion forum.  When and if the C++ discussion threatens to overwhelm
other traffic there, I'm sure Marc would be amenable to opening up a
new list --- but for now, interfaces is the right place.

As for places to host the code, I believe both pgsql.com and
greatbridge.com have plans to open up CVS servers for Postgres-related
projects.  I don't think either is quite open for business yet, but
try pounding on the door and see what happens...

			regards, tom lane

Tue, 03 Oct 2000 23:33:25 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [INTERFACES] C++ client libs 
On Wed, Oct 04, 2000 at 12:38:35PM +1100, Tim Allen wrote:

> >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.

	My preference would be an easily-overridable function so I could
subclass the parent object and drop in a function to send a BMessage
to an arbitrary BLooper.  Your messaging system may vary...


-- 
Adam Haberlach            | A billion hours ago, human life appeared on
adam@newsnipple.com       | earth.  A billion minutes ago, Christianity
http://www.newsnipple.com | emerged.  A billion Coca-Colas ago was
'88 EX500                 | yesterday morning. -1996 Coca-Cola Ann. Rpt.

Tue, 3 Oct 2000 20:40:40 -0700
Adam Haberlach <adam@newsnipple.com>
Re: C++ client libs