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.
