Re: Consistent \d commands in psql

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>> It might be cute to see if the pattern matches any user functions and if not
>> try again with system functions. So you would still get results if you did
>> "\df rtrim" for example.
>
> Interesting idea. IIUC, \df would give you either all user functions
> *or* all system functions depending on the actual catalog contents,
> while \dfS would always give you just system functions. That means
> there'd be no way to replicate the all-functions-of-both-types behavior
> that has been the default in every prior release. That sounds like
> a recipe for getting complaints --- changing the default behavior is
> one thing, but making it so that that behavior isn't available at
> all is surely going to break somebody's code or habitual usage.

Actually on further thought I wonder if it wouldn't be simpler (and perhaps
more consistent with \d) to just list *all* matches iff a pattern is provided
but list only user functions if *no* pattern is provided.

That would effectively be exactly the current behaviour except that you would
have to do \dfS to get a list of system functions. And yeah, you wouldn't be
able to get a list of all functions whether system or user functions. I
suppose you could do \df *

One --perhaps nice, perhaps not-- property of this is that if you defined a
function named "rtrim" and then did "\df rtrim" it would show you _both_ the
system and user function and make it easier to see the conflict. Whereas the
other behaviour I proposed would hide the system function which might
exacerbate the user's confusion.

> BTW, should we remove the special hack that discriminates against
> showing I/O functions (or really anything that touches cstring) in \df?
> ISTM that was mostly there to reduce clutter, and this proposal solves
> that problem more neatly. I know I've cursed that behavior under my
> breath more than once, but again maybe my usage isn't typical.

. o O Ohh! That's why I can never find them!

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's On-Demand Production Tuning