Samofatov, Nickolay wrote:

> Jim,
>
>
>>>Why is it that bad to have fbintl2? Because people will swap
>>
>>different
>>
>>>versions of it with different collations maybe?
>>>
>>>Do you think that renaming a field masks the intention and
>>
>>closes the
>>
>>>discussion?
>>>
>>>
>>>
>>
>>I think we should decide how we want loadable modules found
>>in the future. There are three non-exclusive candidates:
>>
>> 1. Builtin magic names, e.g. fbintl
>> 2. Configuration file specified directories, which are scanned by
>> wildcard at runtime
>> 3. Configuration file specified library names.
>>
>>I'm inclined towards the latter. Any loadable module can
>>compromise the integrity of the database engine; they should
>>be specified with great care. The new configuration
>>mechanism has places for both system defined and installation
>>specific files, providing backwards compatibility.
>>
>>So, rather than hangle over the name of the intl file, let's
>>decide what we want to do going forward (post FB 2.0), then
>>figure out what the best solution is for the short time.
>>
>>[Please note that I've moved the discussion from admin to
>>architect, and for once, am not double posting]
>
>
> Hardcoded magic names are not nice, I explained in admin why. Imagine
> you enforced all users to define their UDFs in a single library named
> GDS_UDF or something. Would they be happy?
>
> I am inclined to approach 2 which is the currently used approach in the
> engine.
> It allows to install engine plugins without editing configuration files
> which is good for usability.
>
> In any case, even if in future we decide to go way 3 config files or any
> other kind of registry is going to map module names to physical file
> names so there is not going to be any harm from storing module names in
> database anyways.
>

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.


Adriano