On Thu, 08 Mar 2001, Randy Jonasz wrote:
> psgresult::iterator row = res.begin();
> pgresult::iterator end = res.end();
>
> while( start < end ) {
>
> *row >> var1 >> var2;
> //or
> var1 = row["colname"];
> //or
> var1 = row[col];
>
> }
Right! For now I wouldn't so far as to make the result sets
modifiable though. That would be opening a whole new can of
worms. Also, there is the issue of type safety to be dealt
with. I think that has priority over operator << on result
sets.
So initially at least, const_iterators only. But definitely
yes on the sequence algorithms, and perhaps we could find a
meaningful way to work in associative behaviour as well.
One side effect of having a type-safe interface would be that
the COPY command no longer requires complete compile-time
knowledge of a table's definition. If COPY is faster than
INSERT for mass inserts (I have no idea whether it is, but it
might just skip a bit of parsing on the server side and send
less data over the wire), that would allow for faster
data insertion while keeping the program reasonably robust
w.r.t. schema changes.
Another thing that could be done is to also have a more
restricted interface where you don't send SQL at all, and all
operations are encoded in the class interface. That might
make it possible to have more-or-less generic failover built
into the frontend (automatically restore active triggers when
connection to server is recovered, stuff like that).
Jeroen
