Viewing non-system objects in psql

"Greg Sabino Mullane" <greg@turnstep.com> writes:

I maintain that it makes more sense for those few people who regularly look
at system functions to add a "S" than to have everyone else have to do
things such as "\df public."

@@aol(me too).

fwiw, i think "few" may be a bit optimistic here. Don't forget you can do
things like this if you forget what arguments array_lower takes:

db=> \df array_lower
List of functions
Result data type | Schema | Name | Argument data types
------------------+------------+-------------+---------------------
integer | pg_catalog | array_lower | anyarray, integer
(1 row)

Or this to get a list of all the standard array functions.

db=> \df array_*

P.S. The use of capital "s" is possible a source of some of the resistance. It
seems like a lowercase "s" or something else that doesn't need multiple
keystrokes would be a lot easier to type. Is there some limitation on the
\command parser that makes \dfs harder?

--
greg

On Thu, 16 Jun 2005, Greg Sabino Mullane wrote:

I recently submitted a patch that makes all the database objects behave
in the same way as far as the backslash psql commands. Currently, tables
work like this: \dt lists all non-system tables in your path, while
\dtS shows only the system tables. The idea is to expand that functionality
to other database objects, e.g. functions. Currently, \df will show you a
list of *all* functions, including the system ones. Since there are currently
over 1500 system functions, this limits its usefullness. The patch
standardizes everything on the way we do tables and indexes - the user ones
are shown by default, and you add a capital "S" if you really want to see the
system ones. So the patch would have \df show all your functions, \dD show
all your domains, \doS shows the system operators, etc.

This all seems to make sense to me, and I thought the debate was over :),
but there has been some feedback on the patches list and we now seem to
be at an impasse, so I thought I would invite a larger audience (other
than the handful of us that read patches) to comment on this.

I maintain that it makes more sense for those few people who regularly look
at system functions to add a "S" than to have everyone else have to do
things such as "\df public." Of course, there is currently no way to
see all the non-system functions if they are not all contained in one
schema. Some have advocated some sort of configuration variable to control
the behavior, but this seems like extreme overkill to me and will lead to
more confusion, as people forget which "mode" they are in. Far simpler to
simply add a capital "S" for those rare occasions when you need to.

Someone else raised the argument that we should keep them separated because
tables are more important for a working database than functions. I don't buy
this one either: for those of us that use functions, domains, operators, etc.,
they are very, very important indeed. All objects should be treated equally.
It also makes things much easier for users to have everything be consistent,
rather than wondering why "S" is needed in some cases and not others.

I agree with you. I expect to see user-created functions with \df by
default, and rarely look at the system functions. The S addition makes
perfect sense for tables and views, and even though I know about the
current inconsistent behavior, I still forget sometimes and expect \df to
act similarly.

Jon

--
Jon Jensen
End Point Corporation
http://www.endpoint.com/
Software development with Interchange, Perl, PostgreSQL, Apache, Linux, ...

On Thu, Jun 16, 2005 at 07:54:29PM -0000, Greg Sabino Mullane wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I recently submitted a patch that makes all the database objects
behave in the same way as far as the backslash psql commands.
Currently, tables work like this: \dt lists all non-system tables in
your path, while \dtS shows only the system tables. The idea is to
expand that functionality to other database objects, e.g. functions.
Currently, \df will show you a list of *all* functions, including
the system ones. Since there are currently over 1500 system
functions, this limits its usefullness. The patch standardizes
everything on the way we do tables and indexes - the user ones are
shown by default, and you add a capital "S" if you really want to
see the system ones. So the patch would have \df show all your
functions, \dD show all your domains, \doS shows the system
operators, etc.

+1 :)

Cheers,
D
--
David Fetter david@fetter.org http://fetter.org/
phone: +1 510 893 6100 mobile: +1 415 235 3778

Remember to vote!

On 6/16/05, David Fetter <david@fetter.org> wrote:

On Thu, Jun 16, 2005 at 07:54:29PM -0000, Greg Sabino Mullane wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I recently submitted a patch that makes all the database objects
behave in the same way as far as the backslash psql commands.
Currently, tables work like this: \dt lists all non-system tables in
your path, while \dtS shows only the system tables. The idea is to
expand that functionality to other database objects, e.g. functions.
Currently, \df will show you a list of *all* functions, including
the system ones. Since there are currently over 1500 system
functions, this limits its usefullness. The patch standardizes
everything on the way we do tables and indexes - the user ones are
shown by default, and you add a capital "S" if you really want to
see the system ones. So the patch would have \df show all your
functions, \dD show all your domains, \doS shows the system
operators, etc.

+1 :)

Thumbs up from me, too. It fails the test of "least astonishment" for
me when I get a listing of all the system functions with a \df, no
matter how many times I do it. I like the \dfS model!

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

P.S. The use of capital "s" is possible a source of some of the resistance. It
seems like a lowercase "s" or something else that doesn't need multiple
keystrokes would be a lot easier to type. Is there some limitation on the
\command parser that makes \dfs harder?

Not in the parser, per se, but I presume that "S" was chosen becuase "s"
was already taken by sequences, e.g. \ds and \dS already have different
behaviors, and since the order of the letters after the \d does not
really matter, there needed to be a way to let \dSt work. All presumptions
on my part, there may be some more historical reasons. I don't think a capital
S is too much work myself... :)

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200506181059
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iD8DBQFCtDbJvJuQZxSWSsgRAutQAJ4/1UWWQ1awKg+ucvY35rLQKHsRsACfY+kM
t5zaT59WY02+DU2G9MR18zY=
=9Dmn
-----END PGP SIGNATURE-----