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.

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.

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.

> Adriano

Nickolay