|
From: Mike N. <ta...@al...> - 2002-10-31 22:31:59
|
Ann W. Harrison wrote: > How would rdb$sql_keywords be implemented? Dear god, a wild idea that's getting implementation questions this fast! :-) I think it would make most sense to have this as some kind of on-the-fly generated data from the hard-coded keyword set. Putting it in a DB (on-disk) makes no sense to me. This is static hard-coded information about the engine, not the DB. struct "tok" (dsql/keywords.h) should then also probably gain another member, telling what conformance level the keyword have. Probably a simpe enum would suffice, but maybe a bitfield could fit better if there are some bits we would like to OR together (like telling if the keyword it's both SQL_92 and ... whatever? I don't know). As for the resulting virtual table presented from such a select the first field is obvious: KEYWORD An integral field VERSION (DIALECT?)? After that it kind of depends on if the ORing of bits together seems like a good idea or not. If not, a simple string field could suffice. If ORing is accepted I'd however be more reluctant to that approach, since the resulting field could possibly become quite a few characters when needing to append a bunch of strings. Maybe instead map the bits 1:1 to a bunch of BOOLean result set fields in that case? Allowing stuff like: select KEYWORD from RDB$KEYWORDS where ANSI92=TRUE AND <whatever>=FALSE; Then again, maybe this would be overdoing it? > Could users add, delete, update keywords? I'd hope not. It would become a rather interesting situation if a user added a new keyword, without any option to tell neither the parser nor the lexical analyzer 1) where the keyword fits, 2) what it's supposed to do. :-) /Mike |