Andrew Dunstan <andrew@dunslane.net> writes: > On 2022-12-07 We 09:20, Tom Lane wrote: >> Returning to the naming quagmire -- it occurred to me just now that >> it might be helpful to call this style of error reporting "soft" >> errors rather than "safe" errors, which'd provide a nice contrast >> with "hard" errors thrown by longjmp'ing. That would lead to naming >> all the variant functions XXXSoft not XXXSafe.
> I'm not sure InputFunctionCallSoft would be an improvement.
Yeah, after reflecting on it a bit more I'm not that impressed with that as a function name either.
(I think that "soft error" could be useful as informal terminology. AFAIR we don't use "hard error" in any formal way either, but there are certainly comments using that phrase.)
More questions:
* Anyone want to bikeshed about the new SQL-level function names? I'm reasonably satisfied with "pg_input_is_valid" for the bool-returning variant, but not so much with "pg_input_invalid_message" for the error-message-returning variant. Thinking about "pg_input_error_message" instead, but that's not stellar either.
Why not do away with two separate functions and define a composite type (boolean, text) for is_valid to return?
* Where in the world shall we document these, if we document them? The only section of chapter 9 that seems even a little bit appropriate is "9.26. System Information Functions and Operators", and even there, they would need their own new table because they don't fit well in any existing table.
I would indeed just add a table there.
BTW, does anyone else agree that 9.26 is desperately in need of some <sect2> subdivisions? It seems to have gotten a lot longer since I looked at it last.
I'd be inclined to do something like what we are attempting for Chapter 28 Monitoring Database Activity; introduce pagination through refentry and build our own table of contents into it.