On Thu, Mar 7, 2024 at 8:06 PM Amit Langote <amitlangot...@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.....
v42-0001-minor-refactor-SQL-JSON-query-functions-based.no-cfbot
Description: Binary data
v42-0002-minor-refactor-JOSN_TABLE-functions-based-on-.no-cfbot
Description: Binary data
