Re: Performance problem in textanycat/anytextcat

I wrote:
>> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
>>> Marking textanycat as not immutable would forbid using it in
>>> expression indexes, too.

>> True. On the other hand, the current state of affairs allows one to
>> create an index on expressions that aren't really immutable, with
>> ensuing hilarity.

> It strikes me that we could avoid any possible functional regression
> here by having CREATE INDEX perform expression preprocessing (in
> particular, function inlining) before it tests to see if the index
> expression contains any non-immutable functions.

I looked into this and found that it's a pretty trivial change to make
CREATE INDEX do it that way. Furthermore, this will cover us against
a subtle gotcha that was introduced by the addition of default arguments
for functions: what happens if a marked-as-immutable function has a
volatile default argument? I don't think that's an insane combination,
since the function's own processing might be perfectly immutable. But
right now, CREATE INDEX will draw the wrong conclusion about whether a
function call that uses the default is safe to put into an index.

BTW, I looked around for other places where we might be making the same
mistake. AFAICT, these two checks in CREATE INDEX are the only places
outside the planner that use either contain_mutable_functions or
contain_volatile_functions. The ones inside-the-planner are OK because
they are looking at already-preprocessed expressions.

Perhaps this is a backpatchable bug fix. Comments?

regards, tom lane