Re: func.sgml - Mailing list pgsql-hackers

From Tatsuo Ishii
Subject Re: func.sgml
Date
Msg-id 20211005.144035.1419951554076315510.t-ishii@sranhm.sra.co.jp
Whole thread Raw
In response to func.sgml  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
>> You have to be very careful these days when applying stale patches to
>> func.sgml --- there's enough duplicate boilerplate that "patch' can easily
>> be fooled into dumping an addition into the wrong place. 
> 
> This is yet another indication to me that there's probably a good case
> for breaking func.sgml up into sections. It is by a very large margin
> the biggest file in our document sources (the next largest is less than
> half the number of lines).

I am welcome this by a different reason. I have been involved in a
translation (to Japanese) project for long time. For this work we are
using Github. Translation works are submitted as pull requests. With
large sgml files (not only func.sgml, but config.sgml, catalogs.sgml
and libpq.sgml), Github's UI cannot handle them correctly. Sometimes
they don't show certain lines, which makes the review process
significantly hard.  Because of this, we have to split those large
sgml files into small files, typically 4 to 5 segments for each large
sgml file.

Splitting those large sgml files in upstream woudl greatly help us
because we don't need to split the large sgml files.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp



pgsql-hackers by date:

Previous
From: Greg Nancarrow
Date:
Subject: Re: Added schema level support for publication.
Next
From: Greg Nancarrow
Date:
Subject: Re: Added schema level support for publication.