Thread

1. C++ client libs

   Tim Allen <tim@proximity.com.au> — 2000-10-04T01:38:35Z

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

2. Re: [INTERFACES] C++ client libs

   Tom Lane <tgl@sss.pgh.pa.us> — 2000-10-04T03:33:25Z

   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
   
   

3. Re: C++ client libs

   Adam Haberlach <adam@newsnipple.com> — 2000-10-04T03:40:40Z

   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.