Re: function defined (or not), more worries on version 10->14 upgrade

"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> ... And if I know something exists
> in the DB and I want details, doing a name-only search followed by \sf
> seems like it would work well enough.

It could work better though. For example,

regression=# \df *backup*
List of functions
Schema | Name | Result data type | Argument data types | Type
------------+-----------------+------------------+------------------------------------------------------------------------------------------------+------
pg_catalog | pg_backup_start | pg_lsn | label text, fast boolean DEFAULT false | func
pg_catalog | pg_backup_stop | record | wait_for_archive boolean DEFAULT true, OUT lsn pg_lsn, OUT labelfile text, OUT spcmapfile text | func
(2 rows)

regression=# \sf pg_backup_start (label text, fast boolean DEFAULT false)
ERROR: syntax error at or near "text"

It seems annoying that I can't copy-and-paste \df's output to invoke \sf.

Moreover, once I peel that down to what will work:

regression=# \sf pg_backup_start (text, boolean )
CREATE OR REPLACE FUNCTION pg_catalog.pg_backup_start(label text, fast boolean DEFAULT false)
RETURNS pg_lsn
LANGUAGE internal
PARALLEL RESTRICTED STRICT
AS $function$pg_backup_start$function$

it's apparent that \sf isn't even consistent with *itself*.
So I agree that there's room for some polishing here.

I'm not sure how far we can go without breaking backwards compatibility.
OTOH, it looks like \df's ability to consider parameters at all is new
as of v14, so maybe the details don't have a huge constituency yet.

regards, tom lane