On Wed, Dec 7, 2022 at 8:23 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > Andrew Dunstan <and...@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. David J.
