>>> is your function stable/immutable, and if so is it decorated as such.
>>>
>> No, it=B4s 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-effect=
s.
>
> I'd question whether it's sane to have a view with volatile functions i=
n
> it at all. It certainly won't act much like the normal understanding o=
f
> a view ...
I see, thanks for the explanation.
In this case, the side effect is desired. The view should always return=20
a COMMENT. Either directly from one of the tables or generated from the=20
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=20
could declare the original function stable and call another volatile=20
function to store the data, as noted in the docs. But that would be=20
cheating...
Regards,
Jan
