Hi - I am the principal developer of the Gaian Database which uses old style Derby VTIs extensively.
I am currently looking at migrating to Table Functions and have hit some problems - 1 - The main issue is that Table functions seem to require a static return schema defined at registration time. Our VTIs return a variable (dynamic) result schema, based on input arguments - With VTIs, Derby obtains this through the getMetaData() method. Table functions only seem to make use of the VTICosting and RestrictedVTI interfaces from what i can see. 2 - Is there any way that I can resolve the name of the table function at run-time, from within the static method that implements it? I don't think a "catalog look-up" based on my java method name would work because I intend to have multiple table functions referencing it. 3 - I've seen no mention of Table Functions supporting the IFastPath interface. This was useful with VTIs because it avoids the tedious job of having to implement all the ResultSet getxxx() methods. 4 - I've yet to experiment with Table Functions properly, but one issue I had with VTIs was that projected columns (unlike qualifiers) were not pushed through a VIEW defined as a SELECT * on the VTI. Is this something that would work with Table Functions now? 5 - As an aside - Neither VTIs nor Table Functions can have a SYNONYM defined for them. This would be useful to avoid VIEW indirections when trying to achieve a more standard syntax for querying the Table Function or VTI (i.e. "select * from " instead of "select * from new com.ibm.db2j....() T" or "select * from TABLE( (...) ) T") Based on points 1 and 3 above - it seems to me that Table Functions are currently a step behind what VTIs could offer before. Are there any plans to improve them in future? Regards David -- View this message in context: http://apache-database.10148.n7.nabble.com/Limitations-of-Table-Functions-vs-old-VTIs-tp127988.html Sent from the Apache Derby Developers mailing list archive at Nabble.com.
