Re: builtin functions, parameter names and psql's \df

On Wed, Sep 2, 2020 at 7:35 AM Andres Freund <andres(at)anarazel(dot)de> wrote:

> Hi,
>
> on a regular basis I remember a builtin function's name, or can figure it
> out
> using \df etc, but can't remember the argument order. A typical example is
> regexp_*, where I never remember whether the pattern or the input string
> comes
> first.
>
> Unfortunatly \df does not really help with that:
>
> =# \df regexp_split_to_table
>
> ┌────────────┬───────────────────────┬──────────────────┬─────────────────────┬──────┐
> │ Schema │ Name │ Result data type │ Argument data
> types │ Type │
>
> ├────────────┼───────────────────────┼──────────────────┼─────────────────────┼──────┤
> │ pg_catalog │ regexp_split_to_table │ SETOF text │ text, text
> │ func │
> │ pg_catalog │ regexp_split_to_table │ SETOF text │ text, text,
> text │ func │
>
> └────────────┴───────────────────────┴──────────────────┴─────────────────────┴──────┘
>
> If the parameters were named however, it'd be clear:
>
> =# CREATE OR REPLACE FUNCTION pg_catalog.regexp_split_to_table(string
> text, pattern text)
> RETURNS SETOF text
> LANGUAGE internal
> IMMUTABLE PARALLEL SAFE STRICT
> AS $function$regexp_split_to_table_no_flags$function$
>
> =# \df regexp_split_to_table
>
> ┌────────────┬───────────────────────┬──────────────────┬──────────────────────────┬──────┐
> │ Schema │ Name │ Result data type │ Argument data
> types │ Type │
>
> ├────────────┼───────────────────────┼──────────────────┼──────────────────────────┼──────┤
> │ pg_catalog │ regexp_split_to_table │ SETOF text │ string text,
> pattern text │ func │
> │ pg_catalog │ regexp_split_to_table │ SETOF text │ text, text,
> text │ func │
>
> └────────────┴───────────────────────┴──────────────────┴──────────────────────────┴──────┘
>
> (I intentionally left the three parameter version unchanged, to show the
> difference)
>
>
> In the docs we already name the parameters using SQL like syntax, see [1].
> How
> about we actually do so for at least the more common / complicated
> functions?
>

+many

I find myself in the same situation a lot.
I've never realized that's an implementation detail and not something
fundamental preventing the parameters from being named in the built-in
functions.

--
Alex