builtin functions, parameter names and psql's \df

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)postgresql(dot)org
Subject: builtin functions, parameter names and psql's \df
Date: 2020-09-02 05:35:05
Message-ID: 20200902053505.rscfg4ecczi7oog4@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?
It may not be worth adding operator names for every comparator, but for
functions we expect to be used directly it seems worthwhile?

It sure would be some initial work, but it seems doable.

Comments?

A mildly related note: It's a bit annoying that the "Pattern Matching"
documentation page [2] does not appear to contain a link to the documentation
about the individual pattern matching functions [1]. Am I missing something?

Greetings,

Andres Freund

[1] https://www.postgresql.org/docs/current/functions-string.html#FUNCTIONS-STRING-OTHER
[2] https://www.postgresql.org/docs/current/functions-matching.html

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2020-09-02 05:39:55 Re: Parallel copy
Previous Message Amit Kapila 2020-09-02 05:24:47 Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions