refactor func-matching.sgml, make regexp* function more readable
hi.
https://www.postgresql.org/docs/current/functions-matching.html#FUNCTIONS-POSIX-REGEXP
section3 way too big.
The first big part is all these (regexp*) functions, the second part
is (9.7.3.1. Regular Expression Details )
Please check the attached refactoring. output sample picture also attached.
All these functions (regexp_count, regexp_instr, regexp_like, regexp_match,
regexp_matches, regexp_replace, regexp_split_to_array, regexp_split_to_table,
regexp_substr) are explained/described one after another, which makes the
section (9.7.3 first part) feels a bit condensed.
So I’ve split them up and enclosed each in its own <sect4> section.
I used <synopsis> to mark up each function’s syntax, followed by a detailed
description. Since each function’s explanation is quite long, using <sect4> to
separate them seems more reasonable.
we could use <table> to group them, like
https://www.postgresql.org/docs/current/functions-json.html#SQLJSON-QUERY-FUNCTIONS
but we have many functions here, using <sect4> would be better than <table>.
jian he <jian.universality@gmail.com> writes:
https://www.postgresql.org/docs/current/functions-matching.html#FUNCTIONS-POSIX-REGEXP
section3 way too big.
All these functions (regexp_count, regexp_instr, regexp_like, regexp_match,
regexp_matches, regexp_replace, regexp_split_to_array, regexp_split_to_table,
regexp_substr) are explained/described one after another, which makes the
section (9.7.3 first part) feels a bit condensed.
So I’ve split them up and enclosed each in its own <sect4> section.
I used <synopsis> to mark up each function’s syntax, followed by a detailed
description. Since each function’s explanation is quite long, using <sect4> to
separate them seems more reasonable.
Yeah, this is clearly an improvement.
we could use <table> to group them, like
https://www.postgresql.org/docs/current/functions-json.html#SQLJSON-QUERY-FUNCTIONS
but we have many functions here, using <sect4> would be better than <table>.
Agreed. I didn't try to put these into tables like most of the other
functions are, precisely because the descriptions and examples are too
long to fit nicely. But splitting the running text using <sect4>
seems helpful, and breaking the syntax summaries out-of-line with
<synopsis> is an improvement too.
I did some janitorial work on this (notably, I think some people's
versions of DocBook don't like id strings containing underscores)
and pushed it.
regards, tom lane