db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Goodacre (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4357) TableFunctions provide no information to limit underlying query
Date Wed, 23 Sep 2009 14:05:16 GMT

    [ https://issues.apache.org/jira/browse/DERBY-4357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12758708#action_12758708

Chris Goodacre commented on DERBY-4357:

Rick, the spec looks good.  I was showing it to a colleague not familiar with TableFunctions
and he was confused slightly by the example of declaring the table function:

create function foreignDatabaseEmployeeTable()
returns table
    id int,
    birthday date,
    taxPayerID varchar( 50 ),
    firstName varchar( 50 ),
    lastName varchar( 50 )
language java
parameter style DERBY_JDBC_RESULT_SET
no sql
external name 'com.acme.portal.foreignDatabaseEmployeeTable'

The external name should be a FQCN + method name, right?    It looks like either you omitted
the classname, or 'portal' is your classname and the lowercase is confusing.

Otherwise the spec looks solid.  Any guestimate on whether our 1 vote will be enough to get
this selected for implementation?   Do I need to sign up all my dead relatives with JIRA accounts
(Chicago-style) to get this over the hump?  :-D

> TableFunctions provide no information to limit underlying query
> ---------------------------------------------------------------
>                 Key: DERBY-4357
>                 URL: https://issues.apache.org/jira/browse/DERBY-4357
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL
>    Affects Versions:,,,,
>         Environment: ALL
>            Reporter: Chris Goodacre
>         Attachments: RestrictedTableFunctions.html, RestrictedTableFunctions.html, RestrictedTableFunctions.html,
> The API specification for TableFunctions cannot provide information to the implementer
of the TableFunction about the details of the query.  For example: 
> (a) I defined a table function named MyFunction with columns a,b, & c
> (b) I bind the table function properly using the CREATE FUNCTION SQL.
> User executes the following SQL:
> select a,b from table ( MyFunction() ) where c = 123
> Without passing the column list and/or where clause as arguments to the table function,
my implementation can not know that it only needs two of the three columns, and only rows
where c = 123.
> For TableFunctions that are built to integrate distant/legacy data, the cost of the query
can be prohibitive.   It would be better if information regarding the columns in the select
and restrictions from the where clause could be passed to the developer.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message