Horton

Re: documentation structure

David G. Johnston <david.g.johnston@gmail.com>

View thread
From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Tatsuo Ishii <ishii@postgresql.org>
Cc: andrew@dunslane.net, corey.huinker@gmail.com, jian.universality@gmail.com, robertmhaas@gmail.com, pgsql-hackers@postgresql.org
Date: 2024-07-19T04:07:20Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. docs: Consistently use <optional> to indicate optional parameters

  2. docs: Consolidate into new "WAL for Extensions" chapter.

  3. freespace: Don't return blocks past the end of the main fork.

  4. docs: Merge separate chapters on built-in index AMs into one.

  5. docs: Demote "Monitoring Disk Usage" from chapter to section.

  6. doc: move system views section to its own chapter

On Thu, Jul 18, 2024 at 8:06 PM Tatsuo Ishii <ishii@postgresql.org> wrote:

> > I'm opposed to having a separate file for every function. I think
> > breaking up func.sgml into one piece per sect1 is about right. If that
> > proves cumbersome still we can look at breaking it up further, but
> > let's start with that.
>
> That will create at least 30 func-xx.sgml files.
>
> t-ishii$ grep '<sect1' func.sgml|wc -l
> 30
>
> I am afraid that's too many?
>
>
The premise and the resultant number of files both seem reasonable to me.
I could get that number down to maybe 20 if pressed but I don't see any
benefit to doing so. I look at a page on the website that needs updating
then go open its source file.  Nice and tidy.

David J.