[
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: 10.4.1.3, 10.4.2.0, 10.5.1.1, 10.5.2.0, 10.5.3.0
> 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.
