Subject | RE: [Firebird-Architect] Re: Design of new built-in functions |
---|---|
Author | Leyne, Sean |
Post date | 2006-05-06T22:46:22Z |
Roman,
functions.
If a user wants a different operation/algorithm, then they are free to
create a UDF which has a custom name.
At Broadview, all of our UDFs have a prefix 'f_' (as in 'f_StripDate()')
so that we clearly understand that the implementation is via UDF,
whereas 'StripDate()' would be a system defined function.
An SDF is implemented within the engine, they are not external to the
engine. As such, they can be implemented in any language which the
engine build can support.
They are 'standard' as defined by the version of the Firebird engine,
they do not vary by database or by platform.
Sean
> Clear, I prefer the second solution, whereI also agree. System functions are never to be overridden by user
> "system-defined functions" cannot be overriden by the user.
functions.
If a user wants a different operation/algorithm, then they are free to
create a UDF which has a custom name.
At Broadview, all of our UDFs have a prefix 'f_' (as in 'f_StripDate()')
so that we clearly understand that the implementation is via UDF,
whereas 'StripDate()' would be a system defined function.
> P.S. Just came to my mind: can it be that you suggest to make the listI disagree with this notion.
> of available system-defined functions (e.g. functions that are
> available without declaration) configurable on per-database level and
> provide a possibility to implement them in different languages?
An SDF is implemented within the engine, they are not external to the
engine. As such, they can be implemented in any language which the
engine build can support.
They are 'standard' as defined by the version of the Firebird engine,
they do not vary by database or by platform.
Sean