Thread: Viewing non-system objects in psql
-----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. 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. The thread that started all this: http://makeashorterlink.com/?W5C91464B http://makeashorterlink.com/?H1FC12BCA (same, non-tree) The recent hackers discussion: http://makeashorterlink.com/?H13A1264B http://makeashorterlink.com/?V24A1264B (same, non-tree) The recent patches discussion: http://makeashorterlink.com/?U2F92164B http://makeashorterlink.com/?E20A3164B (same, non-tree) Thanks, - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200506161509 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iD8DBQFCsdiyvJuQZxSWSsgRAs8JAKD2nmp/i5Ciky7B0xurnKlLxY1akQCeJKpD zN8rYe/95RRSW5E6Y6/LexQ= =0And -----END PGP SIGNATURE-----
"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-----