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 <and...@dunslane.net> wrote: > > > On 3/24/22 16:10, Tom Lane wrote: > > Andrew Dunstan <and...@dunslane.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
