From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Greg Sabino Mullane <htamfids(at)gmail(dot)com> |
Cc: | Ian Lawrence Barwick <barwick(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: psql \df choose functions by their arguments |
Date: | 2021-04-07 23:34:26 |
Message-ID: | 1732246.1617838466@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> Greg Sabino Mullane <htamfids(at)gmail(dot)com> writes:
>> * 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.
I had an idea about that. I've not tested this, but I think it would be
a trivial matter of adding a coalesce() call to make the query act like
the type name for a not-present argument is an empty string, rather than
NULL which is what it gets right now. Then you could do what I think
you're asking for with
\df foo integer ""
Admittedly this is a bit of a hack, but to me this seems like a
minority use-case, so maybe that's good enough.
As for the point about "int" versus "integer" and so on, I wouldn't
be averse to installing a mapping layer for that, so long as we
did it to \dT as well.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2021-04-07 23:37:36 | Re: proposal - psql - use pager for \watch command |
Previous Message | Tom Lane | 2021-04-07 23:01:25 | Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view? |