Date: Sun, 11 Mar 2001 20:20:10 +0100
From: "J. T. Vermeulen" <jtv@cistron.nl>
To: Randy Jonasz <rjonasz@click2net.com>
Cc: "J.T.Vermeulen" <jtv@cistron-office.nl>, pgsql-interfaces@postgresql.org
Subject: Re: libpq++
Message-ID: <20010311202010.B29078@cistron.nl>
Mail-Followup-To: Randy Jonasz <rjonasz@click2net.com>,
	"J.T.Vermeulen" <jtv@cistron-office.nl>,
	pgsql-interfaces@postgresql.org
References: <20010308000250.I3900@cistron.nl>
	<Pine.BSF.4.30.0103081616250.29576-100000@nietzsche.jaded.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.BSF.4.30.0103081616250.29576-100000@nietzsche.jaded.net>;
	from rjonasz@click2net.com on Thu, Mar 08, 2001 at 04:31:19PM
	-0500

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