Marko Kreen <mark...@gmail.com> writes: > On Thu, Mar 29, 2012 at 06:56:30PM -0400, Tom Lane wrote: >> Marko Kreen <mark...@gmail.com> writes: >>> Second conclusion is that current dblink row-processor usage is broken >>> when user uses multiple SELECTs in SQL as dblink uses plain PQexec().
>> Yeah. Perhaps we should tweak the row-processor callback API so that >> it gets an explicit notification that "this is a new resultset". >> Duplicating PQexec's behavior would then involve having the dblink row >> processor throw away any existing tuplestore and start over when it >> gets such a call. >> >> There's multiple ways to express that but the most convenient thing >> from libpq's viewpoint, I think, is to have a callback that occurs >> immediately after collecting a RowDescription message, before any >> rows have arrived. So maybe we could express that as a callback >> with valid "res" but "columns" set to NULL? >> >> A different approach would be to add a row counter to the arguments >> provided to the row processor; then you'd know a new resultset had >> started if you saw rowcounter == 0. This might have another advantage >> of not requiring the row processor to count the rows for itself, which >> I think many row processors would otherwise have to do. > Try to imagine how final documentation will look like. > Then imagine documentation for PGrecvRow() / PQgetRow(). What's your point, exactly? PGrecvRow() / PQgetRow() aren't going to make that any better as currently defined, because there's noplace to indicate "this is a new resultset" in those APIs either. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers