Re: Consistent \d commands in psql - Mailing list pgsql-patches

From Gregory Stark
Subject Re: Consistent \d commands in psql
Date
Msg-id 87hcejsmle.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: Consistent \d commands in psql  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> "Greg Sabino Mullane" <greg@turnstep.com> writes:
>>> \df Lists all user functions
>>> \df [pattern] Lists both system and user functions matching [pattern]
>>> \df * Lists all system and user functions
>
>> I don't like this for two reasons: the items returned changes based on
>> the existence of args, rather than on the command itself, and more
>> importantly, this would make it inconsistent with the other backslash
>> commands.
>
> I think you misunderstood the context of the discussion.  Whatever we do
> will be done to the whole family of \d commands --- we are just using
> \df as an exemplar.

Hm, I didn't realize that. I thought the reason \df was special was that users
often need to refer to "system" functions. Whereas they never need to refer to
system tables or system sequences etc unless they know that's what they're
looking for.

However, now that I look at the list of \d commands that argument kind of
falls flat. Users also need to find "system" operators, data types, etc.

And I think the same logic as \df applies for those other things too. \dt
pg_class should "just work". And if you create a macaddr data type it doesn't
seem like too much of an imposition to play it safe and have \dT macaddr show
the user that there are now two matching data types.

So I guess I should just play along and pretend that's what I meant all along
:)

--
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com
  Ask me about EnterpriseDB's PostGIS support!

pgsql-patches by date:

Previous
From: Gregory Stark
Date:
Subject: Re: psql command aliases support
Next
From: "Joshua D. Drake"
Date:
Subject: Re: actualized SQL/PSM patch