On 02/09/2020 19:15, Julien Rouhaud wrote:
On Wed, Sep 2, 2020 at 9:13 AM Oleksandr Shulgin
<oleksandr.shul...@zalando.de> wrote:
On Wed, Sep 2, 2020 at 7:35 AM Andres Freund <and...@anarazel.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
