Horton

Re: documentation structure

Tatsuo Ishii <ishii@postgresql.org>

View thread
From: Tatsuo Ishii <ishii@postgresql.org>
To: tgl@sss.pgh.pa.us
Cc: david.g.johnston@gmail.com, andrew@dunslane.net, corey.huinker@gmail.com, jian.universality@gmail.com, robertmhaas@gmail.com, pgsql-hackers@postgresql.org
Date: 2024-07-20T00:47:17Z
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

>> IMO the file name should match the ID of the sect1 element with the leading
>> "functions-" removed, naming the directory "functions".  Thus when viewing
>> the web page the corresponding sgml file is determinable.
> 
> I'd go for shorter myself (ie "func/"), mainly due to the precedent
> of the existing subdirectory which is "ref/" not "reference/".
> It's hardly a big deal though.

I don't have strong preference neither but I agree that "func/" is
more consistent with existing subdirectory names.

Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp