On 2024-02-20 15:44 +0100, David E. Wheeler wrote:
> I’ve tweaked the comments and their order in v7, attached.
>
> This goes back to the discussion of the error raising of
> to_regtype[1], so I’ve incorporated the patch from that thread into
> this patch, and set up the docs for to_regtypemod() with similar
> information.
Makes sense.
> [1]
https://www.postgresql.org/message-id/flat/57E1FDDC-5A38-452D-82D7-A44DA2E13862%40justatheory.com#1ae0b11634bc33c7ad3cd728e43d504e
> - <entry role="func_table_entry"><para role="func_signature">
> + <entry id="format_type" role="func_table_entry"><para role="func_signature">
> <indexterm>
> <primary>format_type</primary>
> </indexterm>
> @@ -25462,7 +25462,7 @@ SELECT collation for ('foo' COLLATE "de_DE");
> </row>
>
> <row>
> - <entry role="func_table_entry"><para role="func_signature">
> + <entry id="to_regtype" role="func_table_entry"><para role="func_signature">
The references are printed as "???" right now. Can be fixed with
xreflabel="format_type" and xreflabel="to_regtype" on those <entry>
elements.
> + <function>to_regtypemod</function> ( <parameter>type</parameter> <type>text</type> )
The docs show parameter name "type" but pg_proc.data does not define
proargnames. So the to_regtypemod() cannot be called using named
notation:
test=> select to_regtypemod(type => 'int'::text);
ERROR: function to_regtypemod(type => text) does not exist
> + Parses a string of text, extracts a potential type name from it, and
> + translates its typmod, the modifier for the type, if any. Failure to
s/typmod, the modifier of the type/type modifier/
Because format_type() already uses "type modifier" and I think it helps
searchability to use the same wording.
--
Erik