Re: jira question

[Satheesh Bandaram]

Manish Khettry wrote: 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. While it may be OK to start with a single base column, I think one or more base column references would be good to support. Useful for functional indexes on area, for example. Or total compensation, which may involve base salary, bonus, commissions etc. 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. Doesn't Derby already support evaluating an _expression_ at DDL time for a default clause? Alter table add column evaluates this default _expression_ at the DDL time. -- 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). Right... Common _expression_ detection needs to be added. Would also be useful to eliminate multiple evaluations of any common (sub-)expressions. Satheesh 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/