db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A B (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-716) Re-enable VTIs
Date Thu, 03 May 2007 20:16:15 GMT

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


Mime
View raw message