On Thu, Nov 2, 2023 at 05:28:20PM +0900, Kyotaro Horiguchi wrote:
> Thank you for continuing this. The additional changes looks
> fine.
>
> Upon reviewing the table again in this line, further potential
> improvements and issues have been found. For example:
>
> character, varchar: don't follow the rule.
> - 'char(length)' blank-padded string, fixed storage length
> + blank-padded string, fixed storage length, format 'char(length)'
So, char() and varchar() are _definition_ synonyms for characater and
character varying, so I put the way you define them at the _front_ of
the text. The "format" is the _output_ format and I put that at the end
for other types. I put numeric() at the front too since its definition
is complex. (I now see numeric should be "precision, scale" so I fixed
that.)
> interval: doesn't follow the rule.
> - @ <number> <units>, time interval
> + time interval, format '[@] <number> <units>'
> (I think '@' is not necessary here..)
Agreed, '@' is optional so removed, and I added "...".
> pg_snapshot:
>
> The description given is just "snapshot", which seems overly simplistic.
>
> txid_snapshot:
>
> The description reads "transaction snapshot". Is this really
> accurate, especially in contrast with pg_snapshot?
Uh, the docs have for txid_snapshot:
user-level transaction ID snapshot (deprecated; see
<type>pg_snapshot</type>)<
Do we want to add "deprecated" in the output.
> pg_brin_bloom_summary, pg_brin_minmax_multi_summary, pg_mcv_list and many:
>
> I'm uncertain whether these types, which lack an input syntax (but
> have an output format), qualify as pseudo-types. Nevertheless, I
> believe it would be beneficial to describe that those types differ
> from ordinary types.
Good point, now labeled as pseudo-types.
Updated patch attached.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.