I think using arbitrarily complex expressions to create indexes may be overkill. Dan's idea of restricting expression indexes on function calls on a single base column (actually one _or more_ base columns shouldn't be that much harder) is probably better.
Isn't storing the expression text for a generated column also problematic? I can think of a few other things -- The expression will also have to be compiled and evaluated for DDL like alter table (drop column) possibly others. -- We'll need a good way to check if two expressions are the same. Obviously a textual comparison may not work. Making sure that two expr's are the same is not trivial if we want to do it right-- say (x+y) > 10 is the same as 10 < (y+x). Manish On 8/3/05, Rick Hillegas <[EMAIL PROTECTED]> wrote: > Thanks, Jeff. I agree. Recompiling these expressions can occur when we > compile the triggering SELECT/UPDATE/INSERT statements. Compiling a > SELECT/UPDATE/INSERT is a relatively heavyweight operation and I don't > think anyone will notice a little extra time spent recompiling these > expressions. > > Cheers, > -Rick > > Jeffrey Lichtman wrote: > > > > >> The expression used for the generated column must be stored in the > >> data dictionary. Does derby serialize expressions? I was looking > >> around in the classes in impl/sq/compile (ValueNode and such) and > >> these classes don't seem to implement Formatable. > > > > > > It would be better to store the expressions as text, and to parse and > > bind them when needed. I learned the hard way while working on the > > internals of other database systems that storing internal data > > structures in the data dictionary causes trouble when the structures > > change. Also, it's useful for users to be able to look at the text of > > their DDL statements. > > > > > > - Jeff Lichtman > > [EMAIL PROTECTED] > > Check out Swazoo Koolak's Web Jukebox at > > http://swazoo.com/ > > > >
