On Mon, 2 Oct 2023 15:18:32 -0500
"Karl O. Pinc" <kop@karlpinc.com> wrote:
Version 7
0001 - I would just call the section:
Capturing Command Results into Variables
I would add commentary in there that it is only possible for variables to take on single value at any given time and so in order to handle multiple row results you need to instantiate a loop as per 43.6.6
0002 - {Inferred | Indirect} Types ?
We are already in the Declarations section so the fact we are declaring new variables is already covered.
"Instead of literally writing a type name you can write variable%TYPE and the system will indirectly apply the then-current type of the named variable to the newly declared variable." (using "copy the then-current" reads pretty well and makes the existing title usable...)
0003 - The noun "Exception" here means "deviating from the normal flow of the code", not, "A subclass of error". I don't see this title change being particularly beneficial.
0004 - Agreed, but "You can raise an error explicitly as described in "Errors and Messages". I would not use the phrase "raise an exception", it doesn't fit.
0005 - This tone of voice is used throughout the introductory documentation sections, this single change doesn't seem warranted.
0006 - Useful. The view itself provides all configuration parameters known to the system, the "or selected" isn't true of the view itself, and it seems to go without saying that the user can add a where clause to any query they write using that view. At most I'd make one of the examples include a where clause.
0007 - I'm leaning toward this area being due for some improvement, especially given the v16 changes bring new attention to it, but this patch doesn't scream "improvement" to me.
0008 - Same as 0007. INHERIT is no longer an attribute though, it is a property of membership. This seems more acceptable on its own but I'd need more time to take in the big picture myself.
That's it for now. I'll look over the other 8 when I can.
David J.