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

Rick Hillegas commented on DERBY-716:
-------------------------------------

I am recording here my understanding of the collation associated with string 
columns in the rows returned by Table Functions. The rules which I think apply 
are in the SQL Standard, part 2. The DDL for Table Functions is described in 
section 11.50. There the declaration of the types of the returned columns are 
governed by the same <data type> production which is used for columns in 
ordinary tables. The <data type> production is described in section 6.1. I 
therefore believe that the same rules apply for determining the collation of 
columns in ordinary tables and in the rowsets returned by Table Functions. For 
Derby this means that if a territory-based collation has been declared for the 
database, then all string columns returned by Table Functions must have 
territory-based collation. In databases which DO NOT have a territory-based 
collation, the collation of string columns returned by Table Functions must be 
the basic collation.

> 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
>            Assignee: Rick Hillegas
>         Attachments: derby-716-01-basic-aa.diff, 
> derby-716-02-DatabaseMetaData-aa.diff, derby-716-03-DatabaseMetaData-aa.diff, 
> derby-716-04-Optimizer-aa.diff, derby-716-05-PublicAPI-aa.diff, 
> derby-716-06-TestEncoding-aa.diff, derby-716-07-dblook-aa.diff, 
> derby-716-08-upgrade-aa.diff, derby-716-09-upgradeLocalization-aa.diff, 
> functionTables.html, 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.

Reply via email to