I would favour option (2) as well. I think it is a good pragmatic ad-
interim solution to use. Often, being quick into the market is as
important as being philosophically right. I think the risks of
painting ourselves in a corner with this are limited.

For the same reasons I liked Jim's proposal for two-tier name spaces,
even though it did have the "timber"."wolf" equals "timber.wolf"
issue.

Yet, we need to think ahead and make sure we have a good upgrade
path. As I think that the procedural engine that Fyracle is building
for PL/SQL may have a future role in retiring blr, I would like to
share how Oracle handles the "override" issue. I think that solution
is nicely balanced. In essence, it is a two-tier name space type
solution.

Oracle has a concept of "packages", in essence compilation units for
user code. There is a package called STANDARD, which is searched if
an unqualified function name does not resolve. The STANDARD package
is automatically loaded when a database is created.

In a user package, the built-in functions can be overridden by doing
a local definition. The original is still available by using
STANDARD.<fun_name>, e.g. STANDARD.LOWER. The local definition is not
visible outside the package as an unqualified name.

For special cases, DBA's have the opportunity to remove the default
STANDARD package and loading a new, custom version. These definitions
would behave towards the users as if they were the built-ins.

Of course, this is all at the user level. To the best of my
understanding, the built-ins in the default STANDARD are executed by
code 'inside' the core engine, through some compiler trickery.

Paul