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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size
Следующее
От: Kirk Wolak
Дата:
Сообщение: Proposal: :SQL_EXEC_TIME (like :ROW_COUNT) Variable (psql)