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
-
Allow psql's \df and \do commands to specify argument types.
- a3027e1e7f3d 14.0 landed