[
https://issues.apache.org/jira/browse/DERBY-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511576
]
Rick Hillegas commented on DERBY-716:
-------------------------------------
Hi Dan. I have added a comment to derby-2917. Thanks for tackling that project.
I am very interested in this conversation. Unfortunately, tomorrow is my last
day before I go on vacation (and then a conference) for two and a half weeks.
So, please don't be put off by my impending radio-silence.
> I see that isRowMultiSet is used to indicate the function is a table
> function. Would it not be clearer to have an explict state in
> RoutineAliasInfo that the function is a table function, rather than
> overloading the return type to indicate this?
It seemed to me that a Table Function was just a function which returned a Row
Multi Set. I think it would certainly be reasonable to add an isTableFunction()
method to RoutineAliasInfo. However, to avoid duplicating state, I think that
that method would just turn around and inspect the return type to see if it
were a Row Multi Set.
> - What infomation will be stored in TypeDescriptorImpl, e.g. scale,
> precision, type name etc.
I'm not sure that a TypeDescriptorImpl would ever be built for a Row Multi Set
as part of implementing Table Functions. The return type is never used at
runtime and is only briefly inspected at compilation time in order to build the
shape of the returned Table. I think you have created derby-2917 because it
seems to you, too, that it's hard to understand how behavior is divided between
the types in the catalog package and the types which actually are persisted to
the catalogs.
> how does code access the types & names in the multiset?
This is done in FromVTI.createResultColumnsForTableFunction().
> Re-enable VTIs
> --------------
>
> Key: DERBY-716
> URL: https://issues.apache.org/jira/browse/DERBY-716
> Project: Derby
> Issue Type: New Feature
> Components: SQL
> Reporter: Rick Hillegas
> Assignee: Rick Hillegas
> Attachments: derby-716-01-basic-aa.diff, functionTables.html,
> functionTables.html, functionTables.html
>
>
> Cloudscape used to expose Virtual Table Interfaces, by which any class which
> implemented ResultSet could be included in a query's FROM list. Derby still
> exposes a number of these VTIs as diagnostic tools. However, Derby now
> prevents customers from declaring their own VTIs. The parser raises an error
> if a VTI's package isn't one of the Derby diagnostic packages.
> This is a very powerful feature which customers can use to solve many
> problems. We should discuss the reasons that it was disabled and come up with
> a plan for putting this power back into our customers' hands.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
