On 8/30/12 2:56 PM, David Myers wrote:
...
I think your solution of a table function should work well enough.
> From the few table functions I have used, I notice that I was also
able to get the same info from a join of 2 system tables. Is this how
they generally work (I call the function and an SQL command runs in
the background)?
Hi David,
What you just described sounds more like a view than a table function to
me. Table functions are useful for examining data that comes from
external databases or from non-relational sources. Turning a list into a
table sounds like a good use of table functions to me.
Also would it not make some sense to have a method
within the databaseMetaData object thqt would return either the list
of values (after calling the new function) or take a string argument
and return true (the argument is equivalent to a key word) or false.
This is an interesting approach and might be cheaper to implement. I
think we would only need to add the new method to Derby's embedded
implementation of DatabaseMetaData. We would need to make sure that the
new method had a name which the JDBC expert group would never want to
use. The advantages of a table function (can be used in queries, can be
used across the network by JDBC client apps) could be had by wrapping
the Derby DatabaseMetaData in something like the DBMDWrapper class
attached to https://issues.apache.org/jira/browse/DERBY-3973.
Thanks,
-Rick
