Kjell Rilbe escreveu:

> Adriano dos Santos Fernandes wrote:
>
>> Kjell Rilbe escreveu:
>> > In a databse with default charset UTF8 I have a couple of char(1) and
>> > char(2) columns. I know these are implemented as char(4) and char(8)
>> > behind the scenes to make room for the "worst case" encoding in UTF8,
>> > but it seems that this shines through a bit too much.
>> >
>> > In FlameRobin a select on these columns the displayed data is
>> > right-padded with 3 and 6 spaces respectively.
> [snip]
>> > I don't like it.
>> >
>> Nor I am. But this requires API change or change on how things are
>> described to the client.
>>
>> Basically, we need that CHAR datatype be described with a "length of
>> data" field, like VARCHAR is. This could be accomplished describing CHAR
>> as VARCHAR with a flag or with a new SQL_TYPE. Both ways may impact
>> client components.
>
> So, unless you are willing to do a client-breaking change to the API, it
> is up to the clients to strip the returned data in char(n) columns down
> to n codepoints?
>
> I don't suppose it would work to pad with chr(0) instead of blanks
> (chr(32))?
>
> Could you add a new SQL_TYPE with the new "length of data" but let FB
> use it only if it detects/negotiates with the client that it supports
> is? Does the API currently support version or feature negotiation?
>
> That way, updated clients could have Firebird do the job of returning
> only the relevant bytes and old clients can simply say "hey, I'm old"
> and then FB will do it as today, with the old SQL_TYPE, leaving it up to
> the client to strip all but the first n codepoints?
>

Solution with versioning is possible, but we have more things to change,
for example strings of variable lengths (for system functions
parameters/return). We need to catch all this required changes and
figure out good way to do it all together.


Adriano