From: | Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz> |
---|---|
To: | Julien Rouhaud <rjuju123(at)gmail(dot)com>, Oleksandr Shulgin <oleksandr(dot)shulgin(at)zalando(dot)de> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: builtin functions, parameter names and psql's \df |
Date: | 2020-09-02 07:35:18 |
Message-ID: | 9ab6fe38-fe9d-be67-7d44-b0bcdafb921b@archidevsys.co.nz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2020-09-02 08:05:43 | Re: Kerberos support broken on MSVC builds for Windows x64? |
Previous Message | Julien Rouhaud | 2020-09-02 07:15:12 | Re: builtin functions, parameter names and psql's \df |