[
https://issues.apache.org/jira/browse/DERBY-4357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749807#action_12749807
]
Knut Anders Hatlen commented on DERBY-4357:
-------------------------------------------
Thanks for writing the functional spec, Rick. It looks good and fairly
complete. I have a couple of questions, though:
1) It wasn't entirely clear to me how the _nullEqualsNull field in
Restriction.ColumnQualifier is supposed to be used. Is the user supposed to
specify somehow that this VTI treats NULLs in a non-standard way? If so, how
(and why)? Or is it meant to implement IS (NOT) NULL restrictions? Or something
else?
2) The operator '<>' is not defined. Is that intentional?
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?
4) I cannot find that the spec says what happens if the restricted VTI returns
non-qualifying rows. Should the restrictions be reevaluated outside the VTI? (I
think I would prefer that the restrictions were only seen as hints, so that the
VTI doesn't have to check all of them. Then, if there's a restriction on a
column that doesn't really help the VTI retrieving the rows more efficiently,
it could just disregard that restriction and let the SQL do the filtering
instead.)
> 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.
