[
https://issues.apache.org/jira/browse/DERBY-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493469
]
Rick Hillegas commented on DERBY-716:
-------------------------------------
Thanks for the continued feedback, Army.
> 1) Under "Additional SELECT Syntax"
I welcome additional ideas about how to wordsmith this. I'm trying to
accomplish the following:
a) Indicate that I'm not planning to support any syntax that doesn't currently
work for the diagnostic vtis--at the same time, I'm not planning to disable
anything that is useful and already implemented.
b) Sketch what can be said about this in the user manuals.
I think I have accomplished (a) but I agree that (b) is a bit fuzzy. To me, the
wording that you suggest doesn't cover the following case:
select s.schemaName, t.tableName
from sys.sysschemas s, sys.systables t
where t.schemaid=s.schemaid
and exists
(
select vti.*
from table ( syscs_diag.space_table( s.schemaName, t.tableName ) ) as vti
where vti.numfreepages > 100
);
Here the arguments to the VTI constructor are variables in the context of the
outer query block but constants in the context of the inner block. What do you
think of something like the following: "Table Function arguments must resolve
to expressions which are evaluated once in the context of their query block.
This includes literals and ? parameters but may also include the return values
of function calls as well as correlated references to columns in outer query
blocks."
> 2) Under "Appendix E: Sample VTI"
I am sorry that this is so confusing. In my example, I am admitedly waving my
hands over the complexity of managing connections to an external database. This
is not how someone would really write this VTI. In additon to the awkwardness
of closing down the whole VTI, this example is simply not re-entrant: If two
different connections tried to use this VTI, they would trip over one another.
Writing a bullet-proof VTI like this requires some work, which I think someone
will want to do (and hopefully donate to the community). I'm not taking on that
task as part of writing this functional spec. I will add some words to note
that I'm waving my hands here.
> 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, 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.
