db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-716) Re-enable VTIs
Date Tue, 10 Jul 2007 21:37:04 GMT

    [ 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

> 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

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

View raw message