Re: Various small doc improvements; plpgsql, schemas, permissions, oidvector

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: "Karl O(dot) Pinc" <kop(at)karlpinc(dot)com>
Cc: Daniel Gustafsson <daniel(at)yesql(dot)se>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Various small doc improvements; plpgsql, schemas, permissions, oidvector
Date: 2023-10-03 21:51:31
Message-ID: CAKFQuwayanuVQc=GTMpXN5Txt8JzPdS1T_cDtqsAYVXm7TQNhQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Oct 3, 2023 at 10:56 AM Karl O. Pinc <kop(at)karlpinc(dot)com> wrote:

> On Mon, 2 Oct 2023 15:18:32 -0500
> "Karl O. Pinc" <kop(at)karlpinc(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Borisov 2023-10-03 21:58:49 Re: Index range search optimization
Previous Message Tom Lane 2023-10-03 21:46:51 Re: Allow deleting enumerated values from an existing enumerated data type