Comment for solution 2:
And what about definition (access) of this function in config file.
This mean enable/disable new (all?) build-in function by engine config file.
Default will be all "internals" function enabled, but user can disable
and override by UDF.
Also this solution seems to be faster than (1).

From other point of view, I don't prefer overriding of internal function
because it is hard to understand what can "standard" SQL do.

Slavek

> Proposal (2) designs SDFs at the EVL layer. The engine looks
> up the hardcoded list of SDFs before querying RDB$FUNCTIONS
> and, if the function is SDF, it just call local functions. By
> "local" I mean that all SDFs are implemented as static
> functions inside EVL, the same way as engine functions are
> handled now. Of course, everything is passed via descriptors
> and returned via an impure area. The advantages of this
> approach is that is keeps the current layering and avoids
> calling the almost useless FUN code. The disadvantage is that
> SDFs override UDFs, so users cannot implement their own
> version of the built-in functions.
>
> IMO, such a function override sounds like a useful feature,
> so (1) looks better here. But please note that we never
> supported it and (2) exactly fits our current behaviour. Now,
> when we add a new built-in function, it hides the UDF with
> the same name and call syntax.
>
> My vote goes to (2), as otherwise we'll have undefined
> behaviour - some functions (new ones) can be overriden by
> UDFs whilst others cannot (old ones). As soon as we move away
> from BLR, we could reconsider this behaviour and allow UDFs
> to override all SDFs.