Horton

Re: documentation structure

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Corey Huinker <corey.huinker@gmail.com>, jian he <jian.universality@gmail.com>, Robert Haas <robertmhaas@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2024-07-18T20:40:49Z
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

Andrew Dunstan <andrew@dunslane.net> writes:
> I'm opposed to having a separate file for every function.

I also think that would be a disaster.  It would result in a huge
number of files which would make global editing (eg markup changes)
really painful, and it by no means flattens the document structure.
Somewhere there will still need to be decisions that functions
A, B, C go into one documentation section while D, E, F go somewhere
else.

> 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.

+1

			regards, tom lane