Why is the built-in lower() function variant?

As we know, when creating a functional index, the function needs to be non variant. So, for instance if we want to create an index on the result of lower() on a field, we need to wrap it in a UDR and declare it as NOT VARIANT. But why is lower() considered a variant function? If it was really, truly variant, it would not help wrapping it in a UDR, IMHO. I suppose the wrapping is having a performance cost, hopefully quite small, but especially when building the index initially, the function is called a lot of times, and a direct function call to the built-in function should be faster. Is there anyone with insight in this? ------------------------------ Øyvind Gjerstad Developer/Architect PostNord AS ------------------------------ #Informix

Hi Øyvind, a technically correct, yet maybe not too satisfying answer might be: it's not that lower() is considered variant, but that it is an internal function rather than a user defined one. You can tell the first part from a statement like "create index i_lname on customer (upper(lname));" running onto 9844: Invalid function (upper) used in a functional key.rather than 9848 Functional key part cannot use a variant function function_name. A feature request to allow at least some internal SQL functions for functional indices might be useful, though I'd have no idea how much it takes to implement this or whether there already was a decision against this. HTH, Andreas ------------------------------ Andreas Legner ------------------------------