From: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: identifying unrecognized node type errors |
Date: | 2022-03-28 14:17:42 |
Message-ID: | CAExHW5sd6kAyjgXvL1m-R9q7N2nKsGn4_z3BYtUs2cRzdGE6sw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Mar 25, 2022 at 7:23 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2022-03-28 14:30:32 | Re: SQL/JSON: functions |
Previous Message | James Coleman | 2022-03-28 13:54:35 | Re: Document atthasmissing default optimization avoids verification table scan |