Chris <chris@bitmead.com> writes:
> 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.
Right, so if you really want to destroy retrieved tuples one at a time,
you request only one per retrieved PGresult. I claim that the other
case where you want them in small batches (but not necessarily only one
at a time) is at least as interesting; therefore the mechanism should
not be limited to the exactly-one-at-a-time case. Once you allow for
the other requirements, you have something that looks enough like a
PGresult that it might as well just *be* a PGresult.
> 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.
Let's see (examines PGresult declaration). Four bytes for the
resultStatus, four for the errMsg pointer, 40 for cmdStatus,
out of a struct that is going to occupy close to 100 bytes on
typical hardware --- and that's not counting the tuple descriptor
data and the tuple(s) proper. You could easily reduce the cmdStatus
overhead by making it a pointer to an allocated string instead of
an in-line array, if the 40 bytes were really bothering you. So the
above seems a pretty weak argument for introducing a whole new datatype
and a whole new set of access functions for it. Besides which, you
haven't explained how it is that you are going to avoid the need to
be able to represent error status in a PGObject. The function that
fetches the next tuple(s) in a query has to be able to return an
error status, and that has to be distinguishable from "successful
end of query" and from "no more data available yet".
> 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.
And that can't be done from a PGresult because?
So far, the *only* valid reason you've given for inventing a new
datatype, rather than just using PGresult for the purpose, is to save a
few bytes by eliminating unnecessary fields. That seems a pretty weak
argument (even assuming that the fields are unnecessary, which I doubt).
Having to support and document a whole set of essentially-identical
access functions for both PGresult and PGObject is the overhead that
we ought to be worried about, ISTM. Don't forget that it's not just
libpq we are talking about, either; this additional API will also have
to propagate into libpq++, libpgtcl, the perl5 and python modules,
etc etc etc.
regards, tom lane