Viewing non-system objects in psql

Поиск
Список
Период
Сортировка
От Greg Sabino Mullane
Тема Viewing non-system objects in psql
Дата
Msg-id 4dbdbdc6f3e9818a689edc0c4f715522@biglumber.com
обсуждение исходный текст
Ответы Re: Viewing non-system objects in psql
Re: Viewing non-system objects in psql
Re: Viewing non-system objects in psql
Список pgsql-general
-----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-----



В списке pgsql-general по дате отправления:

Предыдущее
От: Zlatko Matić
Дата:
Сообщение: Re: pg_dumpall
Следующее
От: Joe Maldonado
Дата:
Сообщение: Re: info on strange error messages on postgresql