Re: psql \d* and system objects

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Euler Taveira de Oliveira <euler(at)timbira(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: psql \d* and system objects
Date: 2009-03-30 14:43:01
Message-ID: 603c8f070903300743w2f911fbcl1d3c3324b6cd2827@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 30, 2009 at 10:29 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-03-30 14:51:24 Re: 8.3.5: Crash in CountActiveBackends() - lockless race?
Previous Message Marko Kreen 2009-03-30 14:36:41 Re: 8.3.5: Crash in CountActiveBackends() - lockless race?