[
https://issues.apache.org/jira/browse/DERBY-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493498
]
A B commented on DERBY-716:
---------------------------
> To me, the wording that you suggest doesn't cover the following case:
Can you explain more about why the example is not covered? Is it because of my
use of the term "single value"? If so, we could take that part out:
Let P[i] be the i-th declared parameter for some table function. Let A[i] be
the i-th argument
passed to the table function when it is called.
A table function argument A[i] can be any expression whose corresponding JDBC
type is the same
as the JDBC type which corresponds to the SQL type of the function's declared
parameter P[i].
In the example you give, "s.schemaName" and "t.tableName" are simply
expressions (in this case, column references) whose corresponding JDBC type is
String, hence they are fine (because the JDBC type of the SPACE_TABLE
parameters is String, too).
> 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.
This seems too concentrated on the idea of "evaluated once". The important
thing here isn't how many times the expression is evaluated for a given query;
it's that the expression's datatype match the datatype of the declared function
parameter. Sorry if my previous suggestion made it seem otherwise...
> I will add some words to note that I'm waving my hands here.
On the one hand I agree, having a solid example is not the goal of the spec.
On the other hand, if we can't come up with a solid example, I wonder how
complete/appropriate any proposed solution will end up being? If we cannot get
a good use case of how this feature might be used, it makes it hard to know
whether or not the design is going to be a good one.
An example doesn't have to do anything complex like reference an external
database. It could just be something really simple that, for example, creates
a 2-d array of strings and returns that as a ResultSet. Proof of concept is
what I'm hoping for. As it is, I can't get a good feel for how the proposed
VTIs are actually supposed to be created work from a user perspective...
> 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.
