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

From Brendan Jurd
Subject Re: Consistent \d commands in psql
Date
Msg-id 37ed240d0804011439v5dd316c4j5cfacf8b671ed6df@mail.gmail.com
Whole thread Raw
In response to Re: Consistent \d commands in psql  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Consistent \d commands in psql  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/04/2008, Tom Lane  wrote:
> David Fetter  writes:
>  > When we have a bad default--and I'd argue that for anyone not
>  > developing PostgreSQL itself, showing system functions is a bad
>  > default--we should change it to something sane.
>
> I disagree with your parenthetical argument here, mainly on the strength
>  of Greg's point about how that might hide the existence of conflicts.
>  But in any case the discussion here is first about what set of behaviors
>  we need to provide, and only second about which one should be default.
>

If I read Greg's latter proposal correctly, he was suggesting

\df Lists all user functions
\df [pattern] Lists both system and user functions matching [pattern]
\df * Lists all system and user functions

This doesn't provide is "all system functions only", but:

  1. That list is way too long to be of much use in a psql context
  2. You can still do a \df pg_catalog.* if you're really that keen.

It also doesn't provide "only user functions matching [pattern]", but
is that really a problem?  I suppose you could conceive of a situation
where somebody is looking for all the user funcs matching "int*" and
getting annoyed by having to scroll past ~200 system funcs, but you
can always refine your pattern, or clamp it to a particular schema.

Regards,
BJ
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: http://getfiregpg.org

iD8DBQFH8qtm5YBsbHkuyV0RAkXlAKCH8lL9H8XInLRvlbKnh84XafXyZwCg2Qom
a3TuUMKHH7Yq/zZaA4MI7hk=
=yLQJ
-----END PGP SIGNATURE-----

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: Consistent \d commands in psql
Next
From: Tom Lane
Date:
Subject: Re: actualized SQL/PSM patch