Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s9rqA-005ebF-1J for pgsql-general@arkaria.postgresql.org; Wed, 22 May 2024 19:41:35 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1s9rq9-0039Ou-9m for pgsql-general@arkaria.postgresql.org; Wed, 22 May 2024 19:41:33 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s9rq8-0039LW-Ph for pgsql-general@lists.postgresql.org; Wed, 22 May 2024 19:41:32 +0000 Received: from mail-yb1-xb29.google.com ([2607:f8b0:4864:20::b29]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1s9rq5-001V7b-PU for pgsql-general@postgresql.org; Wed, 22 May 2024 19:41:30 +0000 Received: by mail-yb1-xb29.google.com with SMTP id 3f1490d57ef6-de607ab52f4so5391303276.2 for ; Wed, 22 May 2024 12:41:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716406889; x=1717011689; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=EynTLkeEvbxvOrM2j9MmbMqYmG+kD7f/4ZX8lwlxe7w=; b=koLVhSvsa5G+rQTlHuabA+Ia/WZVCGXB7kNRoG4k4B3brIB2KnJBqnibFYeOoVzomW 9oRNUrD4OFPlgUpt3poo1EBhmZoP5OExB8Vl3rKgMJa1sFy1hV7OdIEgYKQNpPyiHVqG iDKNM3RF2zVGNLmB+6E9o9AcW3wyb1wrHX3te4R5mL8/uU9cfXWeQe3dIwu/eGKppGM2 ftx+ZP4wQfOpU1wPIvso7IbF+a3GtRrv/nxWaW2L0HbS1czvYLeWbpfBSajXilKSERLQ rB8IBW95UOpJgS7yv1k2n3xYfgv1DuZB34Ys+f6Ui487qXfjtcmF2hYIVogWB9R8QdS4 cLkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716406889; x=1717011689; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=EynTLkeEvbxvOrM2j9MmbMqYmG+kD7f/4ZX8lwlxe7w=; b=QJUbOqbiKxuaBYGd9Hge+OHXUvZIH/XSf+NeL6JPSDCa5O/IMEEi7+q8F/3nYwANFa rqjxACdKRlkFJC+uat3UomuVGt2eqZ8/gOnIEKp51japnK8XJGJ7bV/oXdbK8pJ7lTww LFIyI0IEA+QkiFYwU7CjZupm0USLZx9J+cdGcejEEQhfHdkd+6mZRCruGS5sOnGUpeRT vu1Isxoqc9XOW360IUHCEu+S7lQOYyEj4xr/vPn2iKQGsV9uw9F7ltaSFkxXRgJmMErB yKseOMTXdS6pRdDlak9ihZapKZogyfnQk65dSuBfsVVxaw1o9z+hYyWD0daHEHCh5zOq fetA== X-Gm-Message-State: AOJu0YxEqHAJJQ49njvXsLGn84SdKHJeEUYmLIezlEVgfGYr/uE1wluW wg0Sp5OM/zZN5dMIBvGZRUOMka+p0ZvFbdje9Fgp0UNs0taHi4M9frie2pjnT7N0ENWHSABKizV QMzhfHH1uDoyUC8lfhmpwupTrq8M= X-Google-Smtp-Source: AGHT+IFj6d3Yv6Kevk2l4MMYGb2VbqXDYtG26iN9zl6u1mCkkU20LuM63lWWE+kZgc2irg4/wFz5HGD0aiFesRMRxTM= X-Received: by 2002:a25:700a:0:b0:de5:5084:715d with SMTP id 3f1490d57ef6-df4e0df5e91mr2680956276.53.1716406889109; Wed, 22 May 2024 12:41:29 -0700 (PDT) MIME-Version: 1.0 References: <4165841.1716397819@sss.pgh.pa.us> In-Reply-To: From: Pavel Stehule Date: Wed, 22 May 2024 21:40:52 +0200 Message-ID: Subject: Re: search_path and SET ROLE To: Ron Johnson Cc: pgsql-general Content-Type: multipart/alternative; boundary="000000000000ea60ce0619101e14" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000ea60ce0619101e14 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable st 22. 5. 2024 v 21:38 odes=C3=ADlatel Ron Johnson napsal: > On Wed, May 22, 2024 at 2:02=E2=80=AFPM Isaac Morland > wrote: > >> On Wed, 22 May 2024 at 13:48, Ron Johnson >> 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. A= nd 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 wit= h >> 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 tabl= e > 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 --000000000000ea60ce0619101e14 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
st 22. 5. 2024 v=C2=A021:38 odes=C3= =ADlatel Ron Johnson <ronljoh= nsonjr@gmail.com> napsal:
On Wed, May 22, 2024 at = 2:02=E2=80=AFPM Isaac Morland <isaac.morland@gmail.com> wrote:
On Wed, 22 May 2024 at 13:48, Ron Johnson <= ronljohnsonjr@= gmail.com> wrote:

As a superuser administrator, I need to be able to= see ALL tables in ALL schemas when running "\dt", not just the o= nes in "$user" and public.=C2=A0 And I need it to act consistentl= y across all the systems.

\dt *.*

Also shows infor= mation_schema, pg_catalog, and pg_toast.=C2=A0 I can adjust to that, though= .
=C2=A0
<= div dir=3D"ltr">
But I am skeptic= al how often you really want this in a real database with more than a few t= ables. Surely \dn+ followed by \dt [schemaname].* for a few strategically c= hosen [schemaname] would be more useful?
=

More than you'd think.=C2=A0 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

Unfortun= ately=C2=A0 in this case, tab complete doesn't work
--000000000000ea60ce0619101e14--