On Thu, Mar 7, 2024 at 22:46 jian he <jian.universal...@gmail.com> wrote:
> 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..... 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. >
