[
https://issues.apache.org/jira/browse/DERBY-5901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13433486#comment-13433486
]
Rick Hillegas commented on DERBY-5901:
--------------------------------------
Here are some suggestions for how to address this issue:
1) We could make it illegal to declare a function whose unqualifed name would
conflict with the name of a builtin Derby function or operator. Existing
functions which violate this rule could be marked as invalid.
2) We could make all of these user-defined functions behave like the ABS case:
Without a schema qualifier, the name would resolve to the builtin function or
operator. To specify the user-defined function, you would have to qualify it
with its schema name.
Here is my analysis of how these solutions would affect existing applications:
(1)
+ Existing code which invokes the user-defined functions would flat-out break,
forcing the application writer to fix the problem.
- Fixing the problem would be a two part process: i) drop the offending
function and recreate it with a non-conflicting name, then
ii) update existing invocations of the function across the application.
(2)
- Existing code which invokes the user-defined function might silently start
using the builtin function/operator rather than the user-defined function. This
could produce wrong results.
+ Fixing the problem would just be a matter of adding a schema qualification to
existing invocations.
Preferences? Other ideas? Thanks.
> You can declare user-defined functions which shadow builtin functions by the
> same name.
> ---------------------------------------------------------------------------------------
>
> Key: DERBY-5901
> URL: https://issues.apache.org/jira/browse/DERBY-5901
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.10.0.0
> Reporter: Rick Hillegas
>
> You can override a Derby builtin function by creating a function with the
> same name. This can give rise to wrong results.
> Consider the following user code:
> public class FakeSin
> {
> public static Double sin( Double input ) { return new Double( 3.0 ); }
> }
> Now run the following script:
> connect 'jdbc:derby:memory:db;create=true';
> values sin( 0.5 );
> create function sin( a double ) returns double language java parameter style
> java no sql external name 'FakeSin.sin';
> values sin( 0.5 );
> values sin( 0.5 );
> Note the following:
> 1) The first invocation of sin() returns the expected result.
> 2) You are allowed to create a user-defined function named "sin" which can
> shadow the builtin function.
> 3) The second invocation of sin() returns the result of running the builtin
> function. This is because the second invocation is character-for-character
> identical to the first, so Derby just uses the previously prepared statement.
> 4) But the third invocation of sin() returns the result of running the
> user-defined function. Note that the third invocation has an extra space in
> it, which causes Derby to compile it from scratch, picking up the
> user-defined function instead of the builtin one.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
