Greg Sabino Mullane <htamf...@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
