On Tue, Jul 24, 2012 at 6:18 PM, Merlin Moncure <mmonc...@gmail.com> wrote: > On Mon, Jul 23, 2012 at 5:07 PM, Marko Kreen <mark...@gmail.com> wrote: >>> Does PQgetRowData() break the ability to call PQgetvalue() against the >>> result as well as other functions like PQgetisnull()? If so, I >>> object. >> >> I don't get what are you objecting to. The PQgetRowData() >> is called instead of PQgetResult() and it returns zero-row PGresult >> for row header and list of PGdataValues that point to actual >> data. You call the value functions, they don't crash, but as >> the result has zero rows (the data is not copied to it) >> they don't do anything useful either. >> >> The whole point of the API is to avoid the unnecessary copying. >> >> You can mix the calls to PQgetRowData() and PQgetResult() >> during one resultset, it works fine although does not seem >> that useful. >> >> I guess you fear that some code can unexpectedly see >> new behavior, and that exactly why the row-callback API >> needs to be scrapped - it allowed such possibility. >> >> But with PQsetSingleRowMode and PQgetRowData, the >> new behavior is seen only by new code that clearly >> expects it, so I don't see what the problem is. > > Well, for one, it breaks libpqtypes (see line 171@ > http://libpqtypes.esilo.com/browse_source.html?file=exec.c), or at > least makes it unable to use the row-processing mode. libpqtypes > wraps the libpq getter functions and exposes a richer api using only > the result object. When writing libpqtypes we went through great > pains to keep access to server side data through the existing result > API. Note, I'm not arguing that compatibility with libpqtypes is a > desired objective, but the wrapping model that it uses is pretty > reasonably going to be used by other code -- the awkwardness there > should be a red flag of sorts. > > I'm arguing that *all* data getting must continue to do so through the > result object, and bypassing the result to get at data is breaking the > result abstraction in the libpq api. I bet you can still maintain > data access through result object while avoiding extra copies.
Well, the main problem this week is whether we should apply PQsetSingleRowMode() from single-row-mode1 or from single-row-mode2 branch? The PQgetRowData() is unimportant as it just exposes the rowBuf to user and thats all. Do you have opinion about that? > For example, maybe PQsetSingleRowMode maybe should return a result object? What do you mean by that? And have you though about both sync and async usage patterns? -- marko -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
