Doc for ltrim and rtrim
The doc for the trim functions does not say that the second argument can
be omitted. This patch fixes it. It also fixes that the type text was not
wrapped as <type>text</type>.
I can not build the docs myself, but i'm pretty sure it's correct.
Is it okay to commit this? Should I do it on the 7.4 branch also, before
the release?
--
/Dennis Bj�rklund
Attachments:
trim-doc.patchtext/plain; charset=US-ASCII; name=trim-doc.patchDownload+8-5
Dennis Bjorklund wrote:
The doc for the trim functions does not say that the second argument can
be omitted. This patch fixes it. It also fixes that the type text was not
wrapped as <type>text</type>.
Good.
I can not build the docs myself, but i'm pretty sure it's correct.
No problem. See the developers page for 5-minute build so you can check
your commit.
Is it okay to commit this? Should I do it on the 7.4 branch also, before
the release?
Sure. We don't normally backpatch doc adjustment into subreleases, but
you could classify this as a doc bug.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian wrote:
No problem. See the developers page for 5-minute build so you can check
your commit.
I think it's best if people always check that they don't break the
docs before committing changes. "make check" should be sufficient, and
that is much faster than building the docs completely.
-Neil
Dennis Bjorklund <db@zigo.dhs.org> writes:
The doc for the trim functions does not say that the second argument can
be omitted. This patch fixes it. It also fixes that the type text was not
wrapped as <type>text</type>.
It would perhaps be clearer to show the single-argument forms as
separate entries. That would give you room to show an example.
regards, tom lane
Neil Conway wrote:
Bruce Momjian wrote:
No problem. See the developers page for 5-minute build so you can check
your commit.I think it's best if people always check that they don't break the
docs before committing changes. "make check" should be sufficient, and
that is much faster than building the docs completely.
But that assumes he already has SGML tools available, which isn't true
for everyone.
Also, I just tried it here:
(4) cd sgml/
(4) gmake check
LC_ALL=C /usr/bin/perl
/usr/local/share/sgml/docbook-dsssl/bin/collateindex.pl -f -g -o
bookindex.sgml -N
{ \
echo "<!entity version \"7.5devel\">"; \
echo "<!entity majorversion \"`expr 7.5devel :
'\([0-9][0-9]*\.[0-9][0-9]*\)'`\">"; \
} >version.sgml
/usr/bin/perl ./mk_feature_tables.pl YES
../../../src/backend/catalog/sql_feature_packages.txt
../../../src/backend/catalog/sql_features.txt > features-supported.sgml
/usr/bin/perl ./mk_feature_tables.pl NO
../../../src/backend/catalog/sql_feature_packages.txt
../../../src/backend/catalog/sql_features.txt >
features-unsupported.sgml
onsgmls -wall -wno-unused-param -wno-empty -D . -s postgres.sgml
Wow, that was a fast check. I added a syntax error and it did indeed
find it, so it must work well as a checker.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073