Re: identifying unrecognized node type errors

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. For example, if we could annotate the error
message like "while searching for columns to hash" for
expression_tree_walker() called from
find_hash_columns->find_cols->find_cols_walker->expression_tree_walker().
That helps to focus on group by colum expression for example. We could
do that by setting up an error context in find_hash_columns(). But
that's a lot of work.

On Fri, Mar 25, 2022 at 2:04 AM Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
>
> On 3/24/22 16:10, Tom Lane wrote:
> > Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> >> As I was tracking down some of these errors in the sql/json patches I
> >> noticed that we have a whole lot of them in the code, so working out
> >> which one has triggered an error is not as easy as it might be. ISTM we
> >> could usefully prefix each such message with the name of the function in
> >> which it occurs, along the lines of this fragment for nodeFuncs.c. Thoughts?
> > -1. You're reinventing the error location support that already exists
> > inside elog. Just turn up log_error_verbosity instead.
> >
> >
>
>
>
> Yeah, must have had some brain fade. Sorry for the noise.
>
>
> cheers
>
>
> andrew
>
> --
> Andrew Dunstan
> EDB: https://www.enterprisedb.com
>
>
>

--
Best Wishes,
Ashutosh Bapat