db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Myers <david.myers.scibearsp...@gmail.com>
Subject Re: Derby Key Words
Date Thu, 30 Aug 2012 21:56:41 GMT

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?.



On Thu, Aug 30, 2012 at 6:00 PM, Rick Hillegas <rick.hillegas@oracle.com> 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

View raw message