[
https://issues.apache.org/jira/browse/DERBY-672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-672:
--------------------------------
Attachment: derby-672-20-aa-exactBounds.diff
Attaching derby-672-20-aa-exactBounds.diff. This patch tightens up the bounds
checking on the input and return types of user-defined aggregates. Committed at
subversion revision 1400984.
When I simplified bounds checking for input and return types, I lost the
ability to catch some user mistakes at compile time. So for instance, given the
following UDA:
create derby aggregate bigintMode_16 for bigint
external name
'org.apache.derbyTesting.functionTests.tests.lang.GenericMode$IntMode'
...the following statement would fail at run time when the user code tried to
cast a Long to an Integer:
select bigintMode_16( b ) from bigintMode_16_mode_inputs
The solution was to revive the tricky code which I deprecated in patch
derby-672-10-af-typeBounds.diff and to use that tricky code alongside the
simpler bounds checking introduced by that patch. The tricky code catches the
above mismatch at bind() time rather than failing at run time. I am not pleased
by the complexity of the tricky code but I think it is better to catch these
kinds of errors when the statement is compiled.
Touches the following files:
-----------
M
java/engine/org/apache/derby/iapi/services/loader/Java5ClassInspector.java
M java/engine/org/apache/derby/iapi/services/loader/ClassInspector.java
Re-introduce the tricky code.
-----------
M
java/engine/org/apache/derby/impl/sql/compile/UserAggregateDefinition.java
Wire the tricky code back into bind-time type resolution.
-----------
M
java/testing/org/apache/derbyTesting/functionTests/tests/lang/GenericMode.java
While experimenting, I changed the name of the GenericMode type variable from V
to B. This helps to clearly disambiguate it from the V type variable of the
Aggregator class itself. It's a cosmetic change which I think may be useful in
the future if we need to keep improving bounds checking for UDAs.
-----------
M
java/testing/org/apache/derbyTesting/functionTests/tests/lang/UserDefinedAggregatesTest.java
Additional tests.
> Re-enable user defined aggregates
> ---------------------------------
>
> Key: DERBY-672
> URL: https://issues.apache.org/jira/browse/DERBY-672
> Project: Derby
> Issue Type: Improvement
> Components: SQL
> Reporter: Rick Hillegas
> Assignee: Rick Hillegas
> Attachments: derby-672-01-aa-ddl.diff,
> derby-672-02-ac-nonDistinct.diff, derby-672-03-aa-distinct.diff,
> derby-672-03-ab-distinct.diff, derby-672-04-aa-fixJSR169test.diff,
> derby-672-05-aa-java7testOrderProblem.diff, derby-672-06-aa-grantRevoke.diff,
> derby-672-07-aa-fixJSR169again.diff, derby-672-08-aa-fixJSR169yetAgain.diff,
> derby-672-09-ab-udtAggregates.diff, derby-672-10-af-typeBounds.diff,
> derby-672-11-aa-tests.diff, derby-672-11-ab-tests.diff,
> derby-672-12-aa-implicitCasts.diff, derby-672-13-aa-differentReturnType.diff,
> derby-672-14-aa-collations.diff, derby-672-15-aa-setCollation.diff,
> derby-672-16-aa-forbidInGroupBy.diff, derby-672-17-aa-moreTests.diff,
> derby-672-18-aa-udaInJar.diff, derby-672-19-aa-precisionChecks.diff,
> derby-672-20-aa-exactBounds.diff, UserDefinedAggregates.html,
> UserDefinedAggregates.html, UserDefinedAggregates.html
>
>
> Nicolas Dufour in an email thread titled "functions and list" started on
> November 2, 2005 requests the ability to create user defined aggregates.
> This functionality used to be in Cloudscape. It was disabled presumably
> because it was considered non-standard. However, most of the machinery needed
> for this feature is still in the code. We should re-enable user defined
> aggregates after we agree on acceptable syntax.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
