Thread: 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

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