Re: C++ client libs

Thanks for responding so quickly. Your help would be most welcome. I need
to do some further research as well before laying down an API. The
company I work for has offered to set up a CVS box open to the public for
developing this API. There's another person who has expressed interest in
this project as well. What I suggest is working together in developing
concrete/virtual classes with each of their member functions laid out on
paper first. We can then parcel out the actual coding of the classes
between us, using CVS to keep track of our code.

Cheers,

Randy

On Tue, 3 Oct 2000, Adam Haberlach wrote:

> On Tue, Oct 03, 2000 at 02:47:45PM -0400, Randy Jonasz wrote:
>
> > 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 don't really like heavy overloading of stream-type things.
> In this case I think it may make sense, but I prefer
> the db.Exec(sql_string) system for clarity...
>
> > 2) Implement results as a returned object from pg_database
> > result = db.exec();
> > result >> field1 >> field2 >> field3;
> > and
> > field = result["field"];
> > field = result[fieldnum];
>
> The above system puts some state into the result object. Overloading
> array operators can be sketchy, too.
>
> The current system definitely needs to decouple the result from the
> connection. I find that the current API causes most implementations
> to create a lot of independent connections to the backend.
>
> > 3) Implement asynchronous calls to the back-end permitting multiple
> > queries to be executed concurrently
>
> Yes. I was going to do this in order to make use of the NOTIFY/LISTEN
> functionality as well.
>
> > 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.
>
> If you really want exceptions, sure. I don't like 'em myself, but I
> can understand their advantages.
>
> > 5) I'm looking at making the libraries portable between FreeBSD, Solaris
> > Linux and Win32.
>
> Please add BeOS that that list--I'll help keep it in line.
>
> > If anyone has suggestions/additions to this list it would be greatly
> > appreciated!
>
> I'm very interested in helping with this (it is on my list of projects
> and I've managed to stop adding new ones to the list for now). Should
> we take this off-list, or keep it here?
>
> In either case, I'll spend some time formally thinking about my
> perfect API and we can get together and compare notes...
>
> --
> Adam Haberlach | A billion hours ago, human life appeared on
> adam(at)newsnipple(dot)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.
>
>

Randy Jonasz
Software Engineer
Click2net Inc.
Web: http://www.click2net.com
Phone: (905) 271-3550

"You cannot possibly pay a philosopher what he's worth,
but try your best" -- Aristotle