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

On Wed, Sep 2, 2020 at 9:13 AM Oleksandr Shulgin
<oleksandr.shulgin@zalando.de> wrote:
>
> On Wed, Sep 2, 2020 at 7:35 AM Andres Freund <andres@anarazel.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
beingnamed in the built-in functions.
 

Same here, it would be a very nice improvement.