Re: Protocol 3, Execute, maxrows to return, impact?

(I don't really have much to add to the discussion here; I'm just
posting for the record on the question of client behaviour, since
I also wrote and maintain a client library in C++.)

At 2008-07-10 18:40:03 +0200, srb(at)cuci(dot)nl wrote:
>
> I start returning rows as they arrive, and pause reading from the
> network when the application wants to pause.

My library also starts returning rows as they arrive, and in fact my
application makes heavy use of that feature. The data rows are read
from a non-blocking socket and the caller either does something for
each one, or waits until they've all arrived before proceeding.

> Interleaved retrieval using multiple portals is not what most
> libraries support, I'd guess.

My code did support that mode of operation in theory, but in practice
in the few situations where I have needed to use something like it, I
found it more convenient to open explicit cursors and FETCH from them
(but I usually needed this inside a transaction, and so did not open
multiple connections).

Thus my code always sets maxrows to 0 at the moment, and so...

> The only thing I could imagine is that *if* at the server end, the
> notifications that arrive during the retrieval of one long running
> Execute, are queued *after* all the data, instead of inserted into
> the datastream, then it might be worth doing it differently.

...I can't comment on this interesting observation.

> i.e. in one row I can have both text and binary columns, without the
> application needing to specify which is which.

Yes, that's nice. My first attempt to define an API for bind variables
set the data format to text by default and allowed it to be overriden,
but that was much too troublesome. Now the code decides by itself what
format is best to use for a given query.

(Again, though my library certainly supports mixing text and binary
format columns, my application has not needed to use this feature.)

-- ams