-=| Alex Peshkoff, 12.12.2013 17:14:23 +0400 |=-
> On 12/12/13 14:10, Damyan Ivanov wrote:
> > --- a/src/jrd/unicode_util.cpp
> > +++ b/src/jrd/unicode_util.cpp
> > @@ -86,6 +86,11 @@ public:
> >
> > symbol.printf("%s_%d%d", name, majorVersion, minorVersion);
> > module->findSymbol(symbol, ptr);
> > + if (ptr)
> > + return;
> > +
> > + symbol.printf("%s_%d", name, majorVersion);
> > + module->findSymbol(symbol, ptr);
> > }
> >
> > int majorVersion;
> >
> > Symbols in 52.1 are named like:
> > u_init_52
> > uset_clone_52
> > ucase_totitle_52
> > etc.
>
> Quite reasonable. In trunk we already have an array of patterns and a
> loop on it to make it easier to add new rules. BTW, "%s_%d" is present
> in both it and B2_5_Release.
Oh, right. Sorry for missing that commit.
On a related note, I wonder if there is a way to convince firebird to
work with collations created with different (and no longer available)
version of ICU. This would minimise the efforts when upgrading ICU.
Right now, one is required to backup all databases before upgrading,
then restore them after upgrading. With big databases, this is very
time consuming.
I imagine that a way (even a hack) that allows working with existing
databases after upgrading ICU would make it possible to replace the
backup+restore procedure with rebuilding of indices on columns with
Unicode collations. Is this realistic at all?
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel