Re: libpq++
От | J. T. Vermeulen |
---|---|
Тема | Re: libpq++ |
Дата | |
Msg-id | 20010311202010.B29078@cistron.nl обсуждение исходный текст |
Ответ на | Re: libpq++ (Randy Jonasz <rjonasz@click2net.com>) |
Список | pgsql-interfaces |
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
В списке pgsql-interfaces по дате отправления: