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.

Nickolay