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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: 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 15:01:16
Message-ID: 328356.1599058876@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Oleksandr Shulgin <oleksandr(dot)shulgin(at)zalando(dot)de> writes:
> On Wed, Sep 2, 2020 at 7:35 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
>> 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?

> 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.

Yeah, it's not really hard to fix; somebody just has to do the legwork.
The attached is enough to get me to

regression=# \df regexp_split_to_table
List of functions
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 | string text, pattern text, flags text | func
(2 rows)

I don't think we should go overboard on this, but +1 for labeling all the
cases where the usage isn't obvious.

regards, tom lane

Attachment Content-Type Size
label-some-parameter-names.patch text/x-diff 873 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Borisov 2020-09-02 15:42:57 Re: [PATCH] Covering SPGiST index
Previous Message Tom Lane 2020-09-02 14:36:23 Re: describe-config issue