Re: psql \df choose functions by their arguments

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Greg Sabino Mullane <htamfids@gmail.com>
Cc: Ian Lawrence Barwick <barwick@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2021-04-07T21:39:39Z
Lists: pgsql-hackers
Greg Sabino Mullane <htamfids@gmail.com> writes:
> I like the wildcard aspect, but I have a few issues with the patch:

> * It doesn't respect some common abbreviations that work elsewhere (e.g.
> CREATE FUNCTION). So while "int4" works, "int" does not. Nor does "float",
> which thus requires the mandatory-double-quoted "double precision"

"\dT int" doesn't match anything either.  Maybe there's room to improve
on that, but I don't think this patch should deviate from what \dT does.

> * Adding commas to the args, as returned by psql itself via \df, provides
> no matches.

The docs are fairly clear that the args are to be space-separated, not
comma-separated.  This fits with psql's general treatment of backslash
arguments, and I think trying to "improve" on it will just end badly.

> * There seems to be no way (?) to limit the functions returned if they
> share a common root. The previous incantation allowed you to pull out
> foo(int) from foo(int, bigint). This was a big motivation for writing this
> patch.

Hmm, are you trying to say that a invocation with N arg patterns should
match only functions with exactly N arguments?  We could do that, but
I'm not convinced it's an improvement over what I did here.  Default
arguments are a counterexample.

> * SQL error on \df foo a..b as well as one on \df foo (bigint bigint)

The first one seems to be a bug, will look.  As for the second, I still
don't agree that that should be within the mandated syntax.

			regards, tom lane



Commits

  1. Allow psql's \df and \do commands to specify argument types.