db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-672) Re-enable user defined aggregates
Date Thu, 19 Jul 2012 17:20:37 GMT

    [ 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

        

Mime
View raw message