[
https://issues.apache.org/jira/browse/DERBY-5466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-5466:
---------------------------------
Attachment: derby-5466-02-aa-bindLogic.diff
Attaching derby-5466-02-aa-bindLogic.diff. This patch adds bind() logic for
Scott's new aggregates. This patch is not ready for commit. I need to test this
a bit first. But I think the approach may work. With this patch, the new
aggregates can be invoked. If all goes well, then I think the next step is to
write regression tests for this feature.
I decided that creating new aggregate metadata at database creation/upgrade
time was a flawed approach because it would mean that the aggregates would
still have to be invoked with a schema qualifier (e.g. SYS.VAR_POP()). So I
hacked out an alternative solution which just fabricates metadata at bind time.
The approach should be extensible if we want to add more SQL Standard
aggregates using Scott's technique: as implementations of
org.apache.derby.agg.Aggregator. With this patch, adding new builtin aggregates
is a two step process:
1) Add the Aggregator implementations to the org.apache.derby.impl.sql.execute
package.
2) Add descriptors for them to the AggregateNode.BUILTIN_MODERN_AGGS array.
Happily, this solution does not touch the parser or the code generator. Sorry,
Scott, for robbing you of an opportunity to romp through the parser.
Touches the following files:
-----------------------
M java/engine/org/apache/derby/iapi/types/TypeId.java
M java/engine/org/apache/derby/iapi/types/DataTypeDescriptor.java
M java/engine/org/apache/derby/catalog/TypeDescriptor.java
Added some more TypeIds for creating the metadata for the new builtin
aggregates.
-----------------------
M java/engine/org/apache/derby/impl/sql/compile/AggregateNode.java
M java/engine/org/apache/derby/impl/sql/compile/StaticMethodCallNode.java
Made AggregateNode.resolveAggregate() fabricate metadata for the new builtin
aggregates on the fly. The parser thinks that they are functions just as the
parser thinks that user-defined aggregates are functions. Added logic to make
sure that we fail to resolve these aggregates if they are schema-qualified.
-----------------------
M java/engine/org/apache/derby/impl/sql/depend/BasicDependencyManager.java
I tripped across an NPE when the compiler tried to add a dependency between the
statement and the new aggregates. There is no need for such a dependency
because no-one can delete or alter the new aggregates. So I added a little
logic to prevent the dependency manager from trying to do this.
> Add support for SQL Standard statistics functions, such as STDDEV_POP,
> STDDEV_SAMP, VAR_POP, VAR_SAMP
> -----------------------------------------------------------------------------------------------------
>
> Key: DERBY-5466
> URL: https://issues.apache.org/jira/browse/DERBY-5466
> Project: Derby
> Issue Type: Improvement
> Components: SQL
> Affects Versions: 10.8.1.2
> Reporter: Lukas Eder
> Priority: Minor
> Labels: derby_triage10_10
> Attachments: DERBY-5466.stats.patch,
> derby-5466-01-aa-aggregatorClasses.diff, derby-5466-02-aa-bindLogic.diff,
> var_pop_formulas.txt
>
>
> Any of these RDBMS support the SQL standard statistics functions STDDEV_POP,
> STDDEV_SAMP, VAR_POP, VAR_SAMP:
> - DB2 (only STDDEV, VARIANE)
> - H2
> - HSQLDB
> - Ingres
> - MySQL
> - Oracle
> - Postgres
> - SQL Server (named STDEVP, STDEV, VARP, VAR)
> - Sybase ASE
> - Sybase SQL Anywhere
> These don't:
> - Derby
> - SQLite
> This would be a useful addition for Derby, I think.
> An even larger example list of possible statistics aggregate functions is
> listed in the Postgres documentation:
> http://www.postgresql.org/docs/9.0/static/functions-aggregate.html#FUNCTIONS-AGGREGATE-STATISTICS-TABLE
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
