Claudio Valderrama C. wrote:

>>>
>>>
>>ResultSet::getString returns a null terminated string. You use it,
>>assign it to a string class, and copy it before the next "next()". You
>>don't worry about the length. It's a string.
>>
>>
>
>Ah, do you mean deallocating and allocating from the heap specifically for
>each fetch?
>
>

Not your concern. FbDbc may do it stupidly or intelligently. Or it may
start stupidly and get smarter. The pointer, we don't have to expect
the application programmer to handle it intelligently for the interface
to behave efficiently. Somebody has to allocate the space; it might as
well be us, since if we get it wrong, we can also fixed it without
impacting the application program.

>If I'm getting a varchar, with the old schema I simply truncate at
>vary_string[vary_length]
>and keep the same buffer for all the recordset
>whereas with the new, I get a C char, have to apply strlen, allocate
>strlen+1 bytes and transfer the information. Is this the way you devised it?
>
>

Yup. If you were smart, you wouldn't be truncating a data string.
You'd be figuring how to split it or reformat your result. The last
thing we need to worry about is the margin inefficiency of a programmer
doing something really dumb. It would be much better is we made it easy
for the programmer to do the right thing.

>Second, how does a char* based interface deal with anything more than ASCII,
>considering that not only data but identifiers (whatever object names) can
>be expressed in any supported language?
>
>

I thought we had covered that. Everything across the interface is
UTF-8. Period. If we want to put layers that accept and return strings
in runtime specified characters sets, it is easy to do that. Or if we
want to add anoter layer that uses a system defined (mechanism tbd)
character set, we can do that, too.

>Third, the C string is totally useless for retrieving binary information,
>namely OCTETS charset. Do you have an alternative call?
>
>
>

Yup. ResultSet::getBlob and Blob::length() / Block::getSegment.