Horton

Re: documentation structure

Peter Eisentraut <peter@eisentraut.org>

View thread
From: Peter Eisentraut <peter@eisentraut.org>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Andrew Dunstan <andrew@dunslane.net>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2024-03-25T15:26: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 22.03.24 14:59, Robert Haas wrote:
> And I don't believe that if someone were writing a physical book about
> PostgreSQL from scratch, they'd ever end up with a top-level chapter
> that looks anything like our GiST chapter. All of the index AM
> chapters are quite obviously clones of each other, and they're all
> quite short. Surely you'd make them sections within a chapter, not
> entire chapters.
> 
> I do agree that PL/pgsql is more arguable. I can imagine somebody
> writing a book about PostgreSQL and choosing to make that topic into a
> whole chapter.

Yeah, I think there is probably a range of of things from pretty obvious 
to mostly controversial.