Re: identifying unrecognized node type errors

Поиск
Список
Период
Сортировка
От Ashutosh Bapat
Тема Re: identifying unrecognized node type errors
Дата
Msg-id CAExHW5sd6kAyjgXvL1m-R9q7N2nKsGn4_z3BYtUs2cRzdGE6sw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: identifying unrecognized node type errors  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Fri, Mar 25, 2022 at 7:23 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> writes:
> > All these functions are too low level to be helpful to know. Knowing
> > the caller might actually give a hint as to where the unknown node
> > originated from. We may get that from the stack trace if that's
> > available. But if we could annotate the error with error_context that
> > will be super helpful.
>
> Is it really that interesting?  If function X lacks coverage for
> node type Y, then X is what needs to be fixed.  The exact call
> chain for any particular failure seems of only marginal interest,
> certainly not enough to be building vast new infrastructure for.
>

I don't think we have tests covering all possible combinations of
expression trees. Code coverage reports may not reveal this. I have
encountered flaky "unknown expression type" errors. Always ended up
changing code to get the stack trace. Having error context helps.

-- 
Best Wishes,
Ashutosh Bapat



В списке pgsql-hackers по дате отправления:

Предыдущее
От: James Coleman
Дата:
Сообщение: Re: Document atthasmissing default optimization avoids verification table scan
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: SQL/JSON: functions