Samofatov, Nickolay wrote:

> Adriano,
>
>
>>You meant:
>>1) use RDB$MODULE_NAME in system tables to locate the plugin or
>>2) try to load charsets/collations in each plugin?
>>
>>I think (2) is more appropriate for the time being and for the future.
>
>
> Basic objects like charsets, collations and UDFs need to be database
> objects and have dependencies tracked.
> This comes from hard and fast database design rule that external
> configuration information should not change meaning of data or code
> stored in database.
>

Yes, sure.

> You mean that if you are given collation name and charset from
> RDB$COLLATIONS you want to try opening each installed INTL plugin and
> see if it provides collation or not?
> Yes, this may work. It would be ok to load all plugins from INTL
> directory and use them.
>

Yes.

> Anyways, regarding this question I am more inclined to approach 1. For
> tools and even users sometimes it is good to know which module this
> particular charset or collation really comes from.
> Charset/Collation name conflicts would be easier to resolve. For
> example, Firebird user may end up in situation when he needs to use a
> few small bits from two large INTL libraries which significantly
> overlap.
> Module names may be easily made unique by the user, but requiring
> charset/collation names be globally unique may be a burden.
>

Engine should be able to load charsets with only charset name.
This is necessary to open a database when the client is connecting with a charset different from the server OS charset/codepage.

And SQL 2003 remove ability to specify external file in CREATE COLLATION.


Adriano