Re: Query becomes slow when written as view

>>> is your function stable/immutable, and if so is it decorated as such.
>>>
>> No, itŽs volatile.
> Well, that's your problem. The planner won't push down the IN clause
> past the volatile function for fear of changing the query's side-effects.
>
> I'd question whether it's sane to have a view with volatile functions in
> it at all. It certainly won't act much like the normal understanding of
> a view ...

I see, thanks for the explanation.
In this case, the side effect is desired. The view should always return
a COMMENT. Either directly from one of the tables or generated from the
function which stores the COMMENT in cached_comments for the next select.
Is there perhaps a best practice to do a thing like that? Of course we
could declare the original function stable and call another volatile
function to store the data, as noted in the docs. But that would be
cheating...

Regards,
Jan