On 01/04/17 13:30, Dmitry Yemanov wrote: > 04.01.2017 13:13, Dimitry Sibiryakov wrote: >> "This has the added benefit that tools can use this information to determine >> the data >> type consistently based on type and subtype". > AFAIU, ticket suggests to match API's subtype also to field's subtype, > in addition to matching it to the field's charset/collation. But IMO it > means that we cannot have other subtypes for strings in the future. I.e. > subtype 4 cannot be anything else than UTF8 and so on. This looks too > much limiting. >
But what is a reason for mixing subtype and character set at all? That is very bad idea in general. One case is when we talk about subtypes in blobs - that could be thing like BLR, ACL, SDL, JPEG and other graphical formats, etc. Yes, certainly charset is also a kind of format (i.e. a rule how to interpret correctly) for a data, contained in a character field. But we already have a working charsets feature for it! May be first 2 questions should be: - why charset OCTETS should be represented as sybtype, not charset? (reasons provided in the tracker do not look serious) - what else subtypes make sense for character fields (I understand that we may place BLR or even small JPEG data into VARCHAR, but does it really make sense to do such things) ? ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
