"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!
Ask me about EnterpriseDB's On-Demand Production Tuning
In response to
pgsql-patches by date
|Next:||From: Tom Lane||Date: 2008-03-31 15:44:19|
|Subject: Re: Consistent \d commands in psql |
|Previous:||From: Pavel Stehule||Date: 2008-03-31 15:33:42|
|Subject: Fwd: WIP: CASE statement for PL/pgSQL|