[Dbd-firebird-devel] [Firebird-devel] Design issue

[Damyan Ivanov]

-=| Dimitry Sibiryakov, 25.07.2012 21:46:44 +0200 |=-
> 25.07.2012 21:40, marius adrian popa wrote:
> > For CHAR(20) column, when using
> > UTF8 connection charset, sqllen is 80, and there is no way for
> > DBD::Firebird to determine that the column is really CHAR(20).
> 
>    Actually, (sqlsubtype & 0xFF) will tell you that this is UTF8, so 
>    you can easily find out length in chars dividing sqllen by 4.

Here's more about this in case somebody faces the same problem. From 
2.1 Release notes:

 sqlsubtype and Attachment Character Set

 When the character set of a CHAR or VARCHAR column is anything but 
 NONE or OCTETS and the attachment character set is not NONE, the 
 sqlsubtype member of an XSQLVAR pertaining to that column now 
 contains the attachment (connection) character set number instead of 
 the column's character set.

I guess this also means that in the above scenario the data put in the 
XSQLVAR is actually encoded in the character set given by sqlsubtype, 
transcoded if the origin column uses a different character set.

And the &0xff part is (as far as I can find) from 1.5.1 Release notes:

 (while talking about connection character set NONE being able to 
 read/write columns in any character set)
 Abstraction layers that have to manage this can read the low byte of 
 the sqlsubtype field in the XSQLVAR structure, which contains the 
 character set identifier.

Now, DBD::Firebird would only need to get the character set bytes per 
character (from rdb$character_sets.rdb$bytes_per_character) and act 
accordingly.

Thanks for the hints!