Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size
От | Andres Freund |
---|---|
Тема | Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size |
Дата | |
Msg-id | 20230223193953.3uemxkjbz4gjsb4v@awork3.anarazel.de обсуждение исходный текст |
Ответ на | Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size
|
Список | pgsql-hackers |
Hi, On 2023-02-23 13:56:56 -0500, Tom Lane wrote: > Corey Huinker <corey.huinker@gmail.com> writes: > > My not-ready-for-16 work on CAST( ... ON DEFAULT ... ) involved making > > FuncExpr/IoCoerceExpr/ArrayCoerceExpr have a safe_mode flag, and that > > necessitates adding a reserror boolean to ExprEvalStep for subsequent steps > > to test if the error happened. > > Why do you want it in ExprEvalStep ... couldn't it be in ExprState? > I can't see why you'd need more than one at a time during evaluation. I don't know exactly what CAST( ... ON DEFAULT ... ) is aiming for - I guess it wants to assign a different value when the cast fails? Is the default expression a constant, or does it need to be runtime evaluated? If a const, then the cast steps just could assign the new value. If runtime evaluation is needed I'd expect the various coerce steps to jump to the value implementing the default expression in case of a failure. So I'm not sure we even need a reserror field in ExprState. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: