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 Thu, 26 Apr 2007 20:46:15 GMT

    [ https://issues.apache.org/jira/browse/DERBY-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12492109

Rick Hillegas commented on DERBY-716:

Thanks for the great feedback, Army. Your comments will help simplify the next rev of this

> Under the "New SELECT Syntax" section: 

You are correct: I left out the parentheses needed by the TABLE constructor in both the syntax
description and the example.

> A standalone VALUES clause can include other types of expressions, as well. For example:

Function Table invocations will support the same spectrum of expressions that currently work
with the diagnostic VTIs. I will reword this section.

> Under "Type System" 

Yes, I think we need a new datatype for Function Tables, which will be returned by the corresponding
RoutineAliasInfo.getReturnType() method. This returned datatype, in turn, can be used:

1) by the GetProcedureColumns diagnostic vti, which decodes the RoutineAliasInfo on behalf
of java.sql.DatabaseMetaData.getFunctionColumns()

2) by our bind() logic in order to determine the names and types of columns in the derived

Because this datatype is part of RoutineAliasInfo, it will be serialized to SYSALIASES.ALIASINFO.and
that is why it has its own Formatable id.

You are, of course, correct that this is mostly an internal, implementation detail. This new
datatype will only appear to users accidentally since it is part of the contents of SYSALIASES.ALIASINFO,
which users can select and display. We won't be documenting this in the user guides. I will
explain this better in the next rev of the spec.

This particular implementation seems like a fairly straightforward way to deliver (1) and
(2). If you have another idea how to implement (1) and (2), please let me know.

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