Re: psql \d* and system objects - Mailing list pgsql-hackers

From Robert Haas
Subject Re: psql \d* and system objects
Date
Msg-id 603c8f070903300743w2f911fbcl1d3c3324b6cd2827@mail.gmail.com
Whole thread Raw
In response to Re: psql \d* and system objects  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Mar 30, 2009 at 10:29 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> That still has the problem that "\df a*" is horribly inconsistent with
>> "\df".  It might be reasonable to assume that if a name without
>> wildcards is given to any \d command, it should display whatever
>> object it finds, user or system - but I can't see doing it for any
>> wildcard at all.
>
> Why not?  Seems "horribly inconsistent" to me to treat those cases
> differently.
>
> It seems entirely explainable to me to say that "if you specify
> no pattern, the default behavior is to list all non-system functions".
> Where the patch went wrong is in fooling with the behavior when a
> pattern is specified.

Well, what am I supposed to do when I have a large number of
user-defined functions and want only the ones whose names start with
a?

What I like about this patch is that you can search by function (or
aggregate, etc.) name, and, independently of whether you search or
display all, you can include or exclude system functions.  I think
that's a good design.  Now, we can argue about what the default
behavior should be, but at the very minimum I think all combinations
of <search pattern, no search pattern> and <user-defined only, all>
should be possible with some relatively small number of keystrokes.

...Robert


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: PQinitSSL broken in some use casesf
Next
From: Bernd Helmle
Date:
Subject: Re: Error message and infinite date and timestamp conversion in XML