[
https://issues.apache.org/jira/browse/DERBY-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13418464#comment-13418464
]
Rick Hillegas commented on DERBY-672:
-------------------------------------
Thanks for continuing the discussion, Kathey and Mamta. In writing the first
draft of the functional spec, I realized that we would also need GRANT/REVOKE
syntax for user defined aggregates (UDAs). That further tipped me toward
preferring using SQL for declaring/dropping these objects. I thought it would
look odd for some UDA-related DDL operations to happen via SQL and others via
stored procedures. In addition, I decided that using procedures would be a
break with current Derby practice: today we use SQL to create and drop all
other kinds of schema objects. No other kind of schema object is
created/dropped via procedures.
I want to address Mamta's comment about SQL compliance. The word "compliance"
does not appear in the Standard. Probably what is intended here is "SQL
conformance". Every DBMS vendor supports vendor-specific extensions in their
SQL dialects. These extensions don't make their implementations non-conforming.
Non-conformance is caused by failing to implement required features or by
mis-implementing features which are defined by the Standard. SQL conformance is
defined by part 1 chapter 8, part 2 chapter 25, and (for a Java database like
Derby) part 13 chapter 16. In particular, part 1 section 8.4 says:
"An SQL-implementation may provide implementation-defined features that are
additional to those specified by ISO/IEC 9075, and may add to the list of
reserved words."
Vendor-specific extensions must be carefully considered, however. We want to
avoid the following problems:
1) Creating the impression that the extension is Standard and therefore
portable.
2) Increasing the porting burden for applications which need to run on multiple
DBMSes.
3) Creating syntax which may become non-conforming if the Standard defines
conflicting syntax later on.
The proposed syntax does not suffer from these problems, for the following
reasons:
1') The use of the DERBY keyword clearly flags this syntax as a Derby extension.
2') Many DBMSes support UDAs but the Standard has not defined an api in this
area. Using UDAs necessarily causes a porting issue. Simply implementing this
JIRA will hopefully reduce the porting burden because applications will not
have to rewrite their DML in order to workaround Derby's lack of support for
UDAs. I do not see how the porting burden is significantly affected by whether
Derby uses stored procedures vs. SQL.
3') The use of the DERBY keyword insulates us from future changes to the SQL
spec, in case the Standard provides official syntax later on. There is no way
that our syntax would conflict with the Standard and become non-conforming.
Also note that if the Standard did supply official syntax later on, we would
want to consider implementing it, hooking it up to the machinery which this
JIRA will enable. That is true regardless of whether Derby uses stored
procedures or SQL.
However, I am not aware of any interest by the SQL committee in trying to
harmonize the divergent extensions in this area.
Hope this clarifies my reasoning.
Thanks,
-Rick
> 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
> Attachments: 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:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
