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

On 02/09/2020 19:15, Julien Rouhaud wrote:
> 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.

+1