Re: [HACKERS] libpq

Tom Lane wrote:
> How so?  I haven't actually figured out what you think PGobject 
> will do
> differently from PGresult.  Given the considerations I mentioned before,
> I think PGobject *is* a PGresult; it has to have all the same
> functionality, including carrying a tuple descriptor and a query
> status (+ error message if needed).

All I mean to say is that it is often desirable to have control over
when each individual object is destroyed, rather than having to destroy
each batch at once. 

The result status and query status is only temporarily interesting. Once
I know the tuple arrived safely I don't care much about the state of
affairs at that moment, and don't care to waste memory on a structure
that has space for all these error fields.

For example, if I want to buffer the last 20 tuples at all times I could
have..
PGobject *cache[20]
GetFirst() {  for (int i = 0; i < 20; i++)     cache[i] = getNextObject(...);
}

GetNext() {  memmove(&cache[0], &cache[1], sizeof(PGobject *));  cache[19] = getNextObject(...);
}

I don't see why the app programmer shouldn't have to write the loop
GetFirst. Why should this be forced onto libpq when it doesn't help
performance or anything? I don't think, if I understand you correctly,
the PGresult idea doesn't give this flexibility. Correct me if I'm
wrong.

The other thing about PGobject idea is that when I do a real OO database
idea, is that getNextObject will optionally populate user-supplied data
instead. i.e. I can optionally pass a C++ object and a list of field
offsets. So probably I would want getNextObject to take optional args of
a block of memory, and a structure describing field offsets. Only if
these are null does getNextObject allocate space for you.

> > This seems too much responsibility to press onto libpq, but if the user
> > has control over destruction of PQobjects they can buffer what they
> > want, how they want, when they want.
> 
> The app has always had control over when to destroy PGresults, too.
> I still don't see the difference...
> 
>                         regards, tom lane

-- 
Chris Bitmead
mailto:chris@bitmead.com