Re: [HACKERS] libpq
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] libpq |
Дата | |
Msg-id | 5642.950463811@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] libpq (Chris <chris@bitmead.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: