Re: "box" type description

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.