Hi Tomas,

Understood the SP result set must be used "as is", and that limits it as
an instrument for writing reusable code.

My idea behind the question is summarised in assumption 5.

To try an quantify this I have just finished a little test case doing 1M
operations as (100quries x 10K records),(1Kquries x 1K records)
,(10Kquries x 100 records) and (100Kquries x 10 records).

Test 1 :I used python and retrieved the records the "normal" way, and
used (''.join[...]) to join each field of each record interleaved with a
constant string, and saved to a file.

Test 2 :I used a SP to join the fields using temporary variables and
joining the records into chunks of varchar(10000), then python saving
the output.

Test 3 :I used a SP to join the fields using concatenation in the select
and joining the records into chunks of varchar(10000), then python
saving the output.

I ran this on one machine and on a client/server setup.

Result summery:

FB concatenation is always faster than Python.
On a small number of large queries its twice as fast.
On large number of small queries its about 40% faster.

When the client and server is on the same machine (a 1 core VM) they
both run a lot faster than the client/server, however difference between
Python and FB is more pronounced.

On small number of records discrete FB concatenation is about 10% faster
than concatenating in the select, on a large number of records they are
about the same speed.

Conclusion
This is a very limited test case and your results may vary, but I think
based on this result my assumption 4 and 5 is correct.