Subject | Re: [firebird-support] Re: case insensitive Database |
---|---|
Author | Ann W. Harrison |
Post date | 2005-06-02T00:38:17Z |
buppcpp wrote:
direction we're heading is storing all character data as UTF-8 (over the
substantial objections of all non-English European users) and
introducing a new string type without a predefined length. In the
nearer term future, V2 will have a better handle on the effects of
collation on the various string functions - upper, lower (? - what to
do?) like, starting, etc.
Where we came from is this... way way back, before Borland bought
Interbase, we looked at the problems of internationalization and decided
that one character representation and collation per database wasn't
going to work. Two implementation of Kanjii were done, including data
and metadata. The rest was left as an exercise for the student.
Most other database developers took the more reasonable approach that if
your computer only spoke one set of glyphs in one order, then why should
the database argue?
After Borland took over, they did a very flexible implementation of
character sets and collations, accurately mimicking all the quirks of
every other product they cared about. Its a nice, extensible system,
except that no one imagined we'd run out of 255 character sets (mappings
from bytes to glyphs) and 255 collations. Sigh.
So, yes, a default database collation is likely in the middle term
future - possibly V2.x.
Regards,
Ann
>>Err... the good answer may have to wait for Firebird 2.0. ThereNo, that's a good question. Based on my (biased) guesses, the
>
> Will the database every have a default collation like it does with
> character sets, so that you don't have to manually add it to every
> string field?
>
> Or am I mistaken in what I just said?
>
direction we're heading is storing all character data as UTF-8 (over the
substantial objections of all non-English European users) and
introducing a new string type without a predefined length. In the
nearer term future, V2 will have a better handle on the effects of
collation on the various string functions - upper, lower (? - what to
do?) like, starting, etc.
Where we came from is this... way way back, before Borland bought
Interbase, we looked at the problems of internationalization and decided
that one character representation and collation per database wasn't
going to work. Two implementation of Kanjii were done, including data
and metadata. The rest was left as an exercise for the student.
Most other database developers took the more reasonable approach that if
your computer only spoke one set of glyphs in one order, then why should
the database argue?
After Borland took over, they did a very flexible implementation of
character sets and collations, accurately mimicking all the quirks of
every other product they cared about. Its a nice, extensible system,
except that no one imagined we'd run out of 255 character sets (mappings
from bytes to glyphs) and 255 collations. Sigh.
So, yes, a default database collation is likely in the middle term
future - possibly V2.x.
Regards,
Ann