Re: Docs: make source file path references consistent
| От | Chao Li |
|---|---|
| Тема | Re: Docs: make source file path references consistent |
| Дата | |
| Msg-id | 4AC9D74E-C69E-410E-9E1D-19B68715503F@gmail.com обсуждение исходный текст |
| Ответ на | Re: Docs: make source file path references consistent (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Docs: make source file path references consistent
|
| Список | pgsql-hackers |
> On Jan 8, 2026, at 14:44, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Chao Li <li.evan.chao@gmail.com> writes: >> On Dec 25, 2025, at 17:07, Chao Li <li.evan.chao@gmail.com> wrote: >>> This patch is derived from [1]. While reviewing that thread, I noticed that when the documentation refers to .h and .cfilesin the PostgreSQL source tree, it uses a mix of full source-tree paths and short relative paths. This inconsistencycan be confusing for future documentation authors, who may be unsure which form to use. > >> Added to CF for tracking: https://commitfest.postgresql.org/patch/6380/ > > Is this actually worth spending time on? > > Sure, in an ideal world every last line of our source code and > documentation would be totally consistent and read like it had > flowed from a single pen. But the effort to get there seems > out of proportion to the value, and the effort to keep it there > over time would be even more so. That’s a fair point. I agree it’s unrealistic to flow everything from a single pen. I noticed some inconsistencies in boththe source tree and the documentation and was trying to make a small improvement. In my understanding, PG is built bymany contributors around the world, with each person adding a small brick over time. > > I'd be much happier to see us spending time on, say, improving > the many barely-intelligible comments in the code. That takes > serious thought and work though (ChatGPT is unlikely to help). > I will withdraw this patch and put my time elsewhere. Thanks for the perspective. Best regards, -- Chao Li (Evan) HighGo Software Co., Ltd. https://www.highgo.com/
В списке pgsql-hackers по дате отправления: