On Sun, Dec 25, 2022 at 12:13 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Here's a proposed patch for converting regprocin and friends > to soft error reporting. I'll say at the outset that it's an > engineering compromise, and it may be worth going further in > future. But I doubt it's worth doing more than this for v16, > because the next steps would be pretty invasive.
I don't know that I feel particularly good about converting some errors to be reported softly and others not, especially since the dividing line around which things fall into which category is pretty much "well, whatever seemed hard we didn't convert". We could consider hanging it to report everything as a hard error until we can convert everything, but I'm not sure that's better. On another note, I can't help noticing that all of these patches seem to have been committed without any documentation changes. Maybe that's because there's nothing user-visible that makes any use of these features yet, but if that's true, then we probably ought to add something so that the changes are testable. And having done that we need to explain to users what the behavior actually is: that input validation errors are trapped but other kinds of failures like out of memory are not; that most core data types report all input validation errors softly, and the exceptions; and that for non-core data types the behavior depends on how the extension is coded. I think it's really a mistake to suppose that users won't care about or don't need to know these kinds of details. In my experience, that's just not true. -- Robert Haas EDB: http://www.enterprisedb.com