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