On Thu, Mar 7, 2024 at 8:06 PM Amit Langote <amitlangote09@gmail.com> wrote: > > > Indeed. > > This boils down to the difference in the cast expression chosen to > convert the source value to int in the two cases. > > The case where the source value has no quotes, the chosen cast > expression is a FuncExpr for function numeric_int4(), which has no way > to suppress errors. When the source value has quotes, the cast > expression is a CoerceViaIO expression, which can suppress the error. > The default behavior is to suppress the error and return NULL, so the > correct behavior is when the source value has quotes. > > I think we'll need either: > > * fix the code in 0001 to avoid getting numeric_int4() in this case, > and generally cast functions that don't have soft-error handling > support, in favor of using IO coercion. > * fix FuncExpr (like CoerceViaIO) to respect SQL/JSON's request to > suppress errors and fix downstream functions like numeric_int4() to > comply by handling errors softly. > > I'm inclined to go with the 1st option as we already have the > infrastructure in place -- input functions can all handle errors > softly.
not sure this is the right way. but attached patches solved this problem.
Also, can you share the previous memory-hogging bug issue when you are free, I want to know which part I am missing.....
Take a look at the json_populate_type() call in ExecEvalJsonCoercion() or specifically compare the new way of passing its void *cache parameter with the earlier patches.