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?

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