Re: BUG #18097: Immutable expression not allowed in generated at
От | Tom Lane |
---|---|
Тема | Re: BUG #18097: Immutable expression not allowed in generated at |
Дата | |
Msg-id | 1887197.1694189299@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #18097: Immutable expression not allowed in generated at (James Keener <jim@jimkeener.com>) |
Список | pgsql-bugs |
James Keener <jim@jimkeener.com> writes: > The issue here, though, is that it works as an expression for an index, but doesn't work as a generated column unless Iexplicitly cast it to text (which should have happened implicitly anyways). (The cast is turning a non-immutable expressionto be immutable.) The reason that the generated expression fails is that (if you don't explicitly cast to text) then it relies on anytextcat(anynonarray,text), which is only stable, and can't be marked any more restrictively because depending on the type of the non-text argument the corresponding output function might not be immutable. But then why doesn't the equivalent index definition spit up? I found the answer in indexcmds.c's CheckMutability(): /* * First run the expression through the planner. This has a couple of * important consequences. First, function default arguments will get * inserted, which may affect volatility (consider "default now()"). * Second, inline-able functions will get inlined, which may allow us to * conclude that the function is really less volatile than it's marked. As * an example, polymorphic functions must be marked with the most volatile * behavior that they have for any input type, but once we inline the * function we may be able to conclude that it's not so volatile for the * particular input type we're dealing with. * * We assume here that expression_planner() won't scribble on its input. */ expr = expression_planner(expr); /* Now we can search for non-immutable functions */ return contain_mutable_functions((Node *) expr); Applying expression_planner() solves the problem because it inlines anytextcat(anynonarray,text), resolving that the required cast is numeric->text which is immutable. The code for generated expressions omits that step and arrives at the less desirable answer. I wonder where else we have the same issue. regards, tom lane
В списке pgsql-bugs по дате отправления: