Dmitry Yemanov wrote:

> Martijn Tonies wrote:
> >
> > This has nothing to do with fetching data. Having to query the
> > system tables in order to properly process the data as provided
> > by the client side API, does that sound "OK" to you?
>
> I have some doubts about a "proper processing". For a CHAR value, does
> it mean returning (to the caller application) the string with trailing
> spaces of without?

With! Otherwise what would be the purpose of the char type anyway?

> I'd expect a clever intermediate layer to trim them.

I'd puke on such an intermediate layer. It should not fiddle with my
data counter to my specifications.

> But I suspect this makes this issue independent from the multi-byte
> character sets then, because your N (length in characters) is always 10
> for CHAR(10) regardless of the string stored inside (e.g. 'a') and its
> charset. I mean that XSQLVAR may contain either N = 40 or N = 10, and it
> doesn't change anything for you, as you have to decode the partial
> string anyway. Do I miss anything?

I'm not sure what you mean here. The value 40 seems rather silly,
because that would be equal to the buffer size, which is already
available. The value 10 is useful because it allows the application (or
DB component layer) to trim the buffer to the right number of codepoints
using whatever intl library it has at hand.

Kjell
--
--------------------------------------
Kjell Rilbe
DataDIA AB
E-post: kjell@...
Telefon: 08-761 06 55
Mobil: 0733-44 24 64