[
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 spec.
> 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 table
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.
