Re: identifying unrecognized node type errors - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: identifying unrecognized node type errors
Date
Msg-id CAExHW5sd6kAyjgXvL1m-R9q7N2nKsGn4_z3BYtUs2cRzdGE6sw@mail.gmail.com
Whole thread Raw
In response to Re: identifying unrecognized node type errors  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: James Coleman
Date:
Subject: Re: Document atthasmissing default optimization avoids verification table scan
Next
From: Andrew Dunstan
Date:
Subject: Re: SQL/JSON: functions