Rick, I intend to do this during my spare time, even though the need first arose whilst I was at work, this for me will be a strict 'hour or so every in an evening (possibly also weekends... if I'm not busy breaking / renovating the house, taking children to sports clubs etc).
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)? 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. I guess a function somewhat like this must already exist somewhere that looks for the key words in any sql commands - and kicks out an appropriate error message. I'll have a quick look at the file you mention tomorrow. On my original post I mentioned I use eclipse, are there any instructions on how to get eclipse to 'see' the project, I prefer the interface for eclipse over the rather basic editor on L-Ubuntu (and I never really got the hang of emacs or vi), or is there another prefered development platform?. Thanks David. On Thu, Aug 30, 2012 at 6:00 PM, Rick Hillegas <[email protected]> wrote: > On 8/30/12 8:09 AM, David Myers wrote: >> >> Hello Rik, >> >> I thought the JIRA references would help. >> >> In response to your comment. >>> >>> Is it fair to say that you want to give users a programmatic way to list >>> out >>> all of the Derby keywords, reserved and non-reserved, regardless of >>> whether >>> they are keywords in the 2003 rev of the SQL Standard? The point of >>> producing this list is to help developers and IDEs avoid using these >>> words >>> as names of tables, columns, routines, etc.. >>> >> Exactly. As I say I already have the java / sql statements to do this >> (although I have copy / pasted the values from the web page rather >> than grabbing them from the system), I just need to know where I >> should plant them, and how to test that I don't break anything in the >> process ;) ! > > Thanks, David. I think that this would be a useful addition to Derby. I > don't think it requires a new system table. In general, we are reluctant to > add new system tables if a problem can be solved with a simpler mechanism > which doesn't increase the on-disk footprint of every database. > > Instead, I would recommend supplying a diagnostic table function which > behaves as though it were declared as follows: > > create function syscs_diag.derby_keywords() > returns table( keyword varchar( 128 ), isReserved boolean ) > ... > > If you are not familiar with table functions, I recommend reading the > following sections in the user guides: > > o The CREATE FUNCTION section in the Reference Guide. > > o The "Programming Derby-style table functions" section in the Developer's > Guide. > > The actual java code which implements the table function can just extend > org.apache.derby.vti.StringColumnVTI. If you are comfortable with this > solution, I would be happy to coach you through the project. The first thing > you will need to do is sign a contributor license agreement. If you will be > doing this work on behalf of your daytime job, then you will want your > company to sign a corporate contributor license agreement. The first > agreement protects Apache and the second agreement protects you. Information > on these agreements can be found here: http://www.apache.org/licenses/#clas > > Thanks, > -Rick > >
