Re: RFC C++ Interface - Mailing list pgsql-hackers

On Wed, Dec 13, 2000 at 03:16:28PM -0500, Randy Jonasz wrote:
> On Tue, 12 Dec 2000, Nathan Myers wrote:
> > On Tue, Dec 12, 2000 at 05:28:46PM -0500, Bruce Momjian wrote:
> > > > I was co-architect of the Rogue Wave Dbtools.h++ interface design
> > > > ... The design is really showing its age.
> > > Can you suggest areas that should be changed?
> > As I recall, we were much more fond of operator overloading then than is
> > considered tasteful or wise today. Also, there was no standard for how
> > iterators ought to work, then, whereas today one needs unusually good
> > reasons to depart from the STL style.
> 
> Interesting comments.  I can see using the STL framework for iterating
> through result sets being one way to go.  Would something like:
> 
> vector<pgrows>table = pgdb.exec("Select * from foo");
> vector<pgrows>::iterator row;
> vector<pgrows>::iterator end = table.end();
> 
> for( row = table.begin(); row != end; ++row ) {
>   *row >> field1 >> field2;
>   //do something with fields
> }
> 
> be along the lines you were thinking?

No.  The essence of STL is its iterator interface framework.  
(The containers and algorithms that come with STL should be seen
merely as examples of how to use the iterators.)  A better
example would be
 Postgres::Result_iterator end; for (Postgres::Result_iterator it = pgdb.exec("Select * from foo");      it != end;
++it){   int field1;   string field2;   *it >> field1 >> field2;   // do something with fields }
 
(although this still involves overloading ">>").  
The points illustrated above are:

1. Shoehorning the results of a query into an actual STL container is  probably a Bad Thing.  Users who want that can
doit themselves  with std::copy().
 

2. Lazy extraction of query results is almost always better than  aggressive extraction.  Often you don't actually care
about the later results, and you may not have room for them anyhow.
 

Rather than the generic result iterator type illustrated above, with 
conversion to C++ types on extraction via ">>", I would prefer to use 
a templated iterator type so that the body of the loop would look more 
like
 // do something with it->field1 and it->field2

or
 // do something with it->field1() and it->field2()

However, it can be tricky to reconcile compile-time type-safety with 
the entirely runtime-determined result of a "select".  Probably you 
could put in conformance checking where the result of exec() gets 
converted to the iterator, and throw an exception if the types don't 
match. 

Nathan Myers
ncm@zembu.com