On 2022-12-11 Su 12:24, Tom Lane wrote: > Andrew Dunstan <and...@dunslane.net> writes: >> On 2022-12-10 Sa 14:38, Tom Lane wrote: >>> I have not done anything here about errors within JsonbValueToJsonb. >>> There would need to be another round of API-extension in that area >>> if we want to be able to trap its errors. As you say, those are mostly >>> about exceeding implementation size limits, so I suppose one could argue >>> that they are not so different from palloc failure. It's still annoying. >>> If people are good with the changes attached, I might take a look at >>> that. >> Awesome. > I spent some time looking at this, and was discouraged to conclude > that the notational mess would probably be substantially out of > proportion to the value. The main problem is that we'd have to change > the API of pushJsonbValue, which has more than 150 call sites, most > of which would need to grow a new test for failure return. Maybe > somebody will feel like tackling that at some point, but not me today. > >
Yes, I had similar feelings when I looked at it. I don't think this needs to hold up proceeding with the SQL/JSON rework, which I think can reasonably restart now. Maybe as we work through the remaining input functions (there are about 60 core candidates left on my list) we should mark them with a comment if no adjustment is needed. I'm going to look at jsonpath and the text types next, I somewhat tied up this week but might get to relook at pushJsonbValue later in the month. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
