On 31/08/12 15:00, Rick Hillegas wrote:
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
Hello again all.
Things are progressing.... sort of ;)
I've had success in pointing Eclipse to the source code that I have
built. I have had a nice look around for the file that I am interested
in, which from the previously mentioned JIRA issues etc suggest a file
called sqlgrammar.jj
only problem is I can't find it!
This file holds the 2 methods, that I am interested in.
It seems to me that the data must already be locked away somewhere in
derby, but I haven't yet found where. I haven't even found a
databasemetadata.java file... yet ?
I guess I'm missing something somewhere...
David
