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

On Wed, Sep 2, 2020 at 9:13 AM Oleksandr Shulgin
<oleksandr(dot)shulgin(at)zalando(dot)de> wrote:
>
> 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.

Same here, it would be a very nice improvement.