"Kjell Rilbe" wrote:

> 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.
>
> Is this:
>
> 1. A Firebird bug?
>
> 2. A Firebird "feature" (= as designed)? (Why?)
>
> 3. A FlameRobin bug?

It is a FlameRobin bug, because client application has enough informations
to be able to display data correctly.

----

VARCHAR is sent to the client in fixed length buffer, but data additionally contains
"actual length" value. Note that this "length" is number of *bytes*, not *characters*,
so even with VARCHAR some applications are "confused".
E.g. if you need to display data in tabular form, application needs to find out
number of characters, not blindly use the "length" directly from data.
You can see such bug in ISQL - select from VARCHAR(10) UTF8 field,
and the result will be 40 characters wide !

CHAR is sent to the client in fixed length buffer too. If data are encoded in UTF8,
i.e. in variable length encoding, then of course some padding usually occurs.
To get data without padding, all you need is function like

Copy_first_n_utf8_characters_from_given_string (buf, n)

where n is "buffer_length / 4". So, API change propsed by Adriano would be nice,
but not *required*.

----

Actually, what you want is CHAR field that looks like VARCHAR on client side.
Even with current FB version, you have two possibilities to achieve it

* cast you CHAR data to VARCHAR as part of sql command, e.g.

SELECT CAST(MyChar2Field AS VARCHAR(2)) FROM tab;

* by data coercion, i.e. set desired datatype in xsqlda structure

(There were quite a lot of changes in character set handling in recent FB versions,
and I have not tested everything yet, so I can't prove whether above mentioned
methods work correctly - if not, then it should fixed of course.)

----

Kjell, not sure which part of my previous reply you found offending - I simply wanted
to help, that's all.


Ivan