| 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: | Whole Thread | Raw Message | 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 |