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 Tue, 01 Sep 2009 15:54:32 GMT

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

Chris Goodacre commented on DERBY-4357:

>3) The array passed to setMaterializedColumnNames() contains somewhat redundant information
(both names and positions of the columns to >materialize). Would an array of booleans suffice?
Or could the extra information be used for something? 

>>I agree that the information is redundant and my original suggestion was to use a
bitmap. However, Chris reported that this would be >>cumbersome to use in the real world.
I don't think that the redundancy is harmful. In the meantime, I have warmed up to the redundancy.
That's >>because I can see that it will make it very easy to write a generic table function
that wraps a SELECT against a foreign table and allows you to >>push projections and
restrictions into the foreign query. 

Specifically, I noted that a BitMap (or an array of [Bb]ooleans) would force my code (I believe)
to know the order of the columns as they were defined in the function.   Currently, I don't
have that dependency, and if I could get away without it, that was preferable to me.

> 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
> 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