> >> I dislike putting random restrictions on what the \d displays > >> will show. We have done this in the past (eg, \df doesn't show > >> things it thinks are I/O functions) and by and large it's been a > >> mistake; I think it's created more confusion than it's prevented. > > > Hrm... psql's unfortunately an SQL interface to PostgreSQL and an > > administration tool. What would you say to adding a -P switch (power > > user) to psql that'd disable any information hiding: the default would > > be to hide non-critical areas including pg_catalog, pg_toast, > > template1, and template0. \set POWERUSER would also work to toggle > > this.. or just have \P toggle this mode. Thoughts? > > I don't think that really answers my concern, since the sort of > folks who are likely to get confused by not being able to see > something that should be there are exactly the same ones who are not > likely to have turned on a non-default "power user" setting. If > anything, adding such a setting is likely to increase confusion > rather than decrease it, because people will get accustomed to > differing results.
Or overwhelmed by bits that they shouldn't be exposed to... > I'm not dead set on this, and will concede gracefully if there's a > consensus that we should change \dn's behavior. I'm just trying to > make the point that it's a decision with pluses and minuses, not a > no-brainer improvement. *nods* Though I do think that masking pg_temp_* would be useful as I've never seen a need to look inside of a pg_temp_* schema. Someone running with -E would quickly pick up that pg_temp_* is filtered from the results. I have a machine with over 1K persistent connections and over 1K pg_temp_* entries... I've been running with the patch submitted earlier and it cuts down on the visual noise/unnecessary info considerably. Switching between DBA mode and a data consumer with \P sounds pretty appealing to me and would be something I'd be interested in doing the leg work for. Changing the prompt would probably be good from a UI perspective and adding the necessary logic so that if the connecting user had DBA privs, it'd run in a power user mode instead of the normal data consumer mode. -sc -- Sean Chittenden ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster