public inbox for [email protected]help / color / mirror / Atom feed
Re: search_path and SET ROLE 3+ messages / 3 participants [nested] [flat]
* Re: search_path and SET ROLE @ 2024-05-22 18:01 Isaac Morland <[email protected]> 2024-05-22 19:38 ` Re: search_path and SET ROLE Ron Johnson <[email protected]> 0 siblings, 1 reply; 3+ messages in thread From: Isaac Morland @ 2024-05-22 18:01 UTC (permalink / raw) To: Ron Johnson <[email protected]>; +Cc: Tom Lane <[email protected]>; pgsql-general On Wed, 22 May 2024 at 13:48, Ron Johnson <[email protected]> wrote: As a superuser administrator, I need to be able to see ALL tables in ALL > schemas when running "\dt", not just the ones in "$user" and public. And I > need it to act consistently across all the systems. > \dt *.* But I am skeptical how often you really want this in a real database with more than a few tables. Surely \dn+ followed by \dt [schemaname].* for a few strategically chosen [schemaname] would be more useful? ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: search_path and SET ROLE 2024-05-22 18:01 Re: search_path and SET ROLE Isaac Morland <[email protected]> @ 2024-05-22 19:38 ` Ron Johnson <[email protected]> 2024-05-22 19:40 ` Re: search_path and SET ROLE Pavel Stehule <[email protected]> 0 siblings, 1 reply; 3+ messages in thread From: Ron Johnson @ 2024-05-22 19:38 UTC (permalink / raw) To: pgsql-general On Wed, May 22, 2024 at 2:02 PM Isaac Morland <[email protected]> wrote: > On Wed, 22 May 2024 at 13:48, Ron Johnson <[email protected]> wrote: > > As a superuser administrator, I need to be able to see ALL tables in ALL >> schemas when running "\dt", not just the ones in "$user" and public. And I >> need it to act consistently across all the systems. >> > > \dt *.* > Also shows information_schema, pg_catalog, and pg_toast. I can adjust to that, though. > But I am skeptical how often you really want this in a real database with > more than a few tables. Surely \dn+ followed by \dt [schemaname].* for a > few strategically chosen [schemaname] would be more useful? > More than you'd think. I'm always looking up the definition of this table or that table (mostly for indices and keys), and I never remember which schema they're in. ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: search_path and SET ROLE 2024-05-22 18:01 Re: search_path and SET ROLE Isaac Morland <[email protected]> 2024-05-22 19:38 ` Re: search_path and SET ROLE Ron Johnson <[email protected]> @ 2024-05-22 19:40 ` Pavel Stehule <[email protected]> 0 siblings, 0 replies; 3+ messages in thread From: Pavel Stehule @ 2024-05-22 19:40 UTC (permalink / raw) To: Ron Johnson <[email protected]>; +Cc: pgsql-general st 22. 5. 2024 v 21:38 odesílatel Ron Johnson <[email protected]> napsal: > On Wed, May 22, 2024 at 2:02 PM Isaac Morland <[email protected]> > wrote: > >> On Wed, 22 May 2024 at 13:48, Ron Johnson <[email protected]> >> wrote: >> >> As a superuser administrator, I need to be able to see ALL tables in ALL >>> schemas when running "\dt", not just the ones in "$user" and public. And I >>> need it to act consistently across all the systems. >>> >> >> \dt *.* >> > > Also shows information_schema, pg_catalog, and pg_toast. I can adjust to > that, though. > > >> But I am skeptical how often you really want this in a real database with >> more than a few tables. Surely \dn+ followed by \dt [schemaname].* for a >> few strategically chosen [schemaname] would be more useful? >> > > More than you'd think. I'm always looking up the definition of this table > or that table (mostly for indices and keys), and I never remember which > schema they're in. > \d *.pg_class Unfortunately in this case, tab complete doesn't work ^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2024-05-22 19:40 UTC | newest] Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-05-22 18:01 Re: search_path and SET ROLE Isaac Morland <[email protected]> 2024-05-22 19:38 ` Ron Johnson <[email protected]> 2024-05-22 19:40 ` Pavel Stehule <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox