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 1s9rnS-005eJ2-Ig for pgsql-general@arkaria.postgresql.org; Wed, 22 May 2024 19:38:47 +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 1s9rnS-003330-5c for pgsql-general@arkaria.postgresql.org; Wed, 22 May 2024 19:38:46 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s9rnR-00332r-R4 for pgsql-general@lists.postgresql.org; Wed, 22 May 2024 19:38:45 +0000 Received: from mail-oa1-x2c.google.com ([2001:4860:4864:20::2c]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1s9rnP-000Fdy-7u for pgsql-general@postgresql.org; Wed, 22 May 2024 19:38:45 +0000 Received: by mail-oa1-x2c.google.com with SMTP id 586e51a60fabf-2454156db8bso2676184fac.3 for ; Wed, 22 May 2024 12:38:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716406721; x=1717011521; darn=postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=gEYQCPACDdit+X95zJLKgKmkSsrwQDd61ZOPR2qpaqE=; b=UVqIOYBkZhFf0htlAGA1SJcHFs8a6Tm4ntBFFuQsYizkxfEYYyovHK8qErkOC5Qdej wcyD8FjLl+K/A446Po/uSbrZq6nZIZJk0daZiKy2uEvDS6cqoVy5QkMs5VS/Vmxuq0Fn TK9yiT/AFlkam0NibidBz816My6EyH45V1aWgHGOaDXiun3GcWaRAlRnKtLiDmvWtN8m TntD5G+rUsz8yebwYJK9G4TVsjOKLj5pZkPscJw2VyKgDcxJynzRi4e5g5Ovh87t6/4S Y/3IYXQYnzHBLpxqePUttD82/vk8dVGY8yYLxkyJRTh+cmQU6AGCdWGLmbM6dcd8HoRU c1HA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716406721; x=1717011521; h=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=gEYQCPACDdit+X95zJLKgKmkSsrwQDd61ZOPR2qpaqE=; b=mw0+B+4OY8Am3ejH1vbMeMjTYJyu1eiJnsTwvlLRlUhbQCACyMeevuwVpuAzqQJz2V eylrYyPHtG0AIhxS2vDoc/GX9OemTf87UvSORCQ/AWIJp93EzrPFM0euwNTGaTgXaMAg jTAHBLT1tSLa61rdL3RwJLRfgjHxeNKC2i8HtAzzOUSTTURD9f7WjEf5jl79M0tGC2G1 pzpaRf8qcEQccNjFHCOaW9mnUdR48SYP2r5Wvtg0nubVd2t092CkIOtgQ+4odjh3/X6d HSrFDALbVEPh07AfQM2KUsSVqYLOVd1azLY/54flwOnEK04zJfFybui0ITLEXE5GC2QT 6QoA== X-Gm-Message-State: AOJu0Yz4xc009ze1k0B/8IloSyNon9iHqkc2BkG8QOIdl1nQMl7xVYGV l5fl5AiQoa6lSPkLCGzky5SrPCvoR0/wKgEUvTwnTL2YwW8YB0QQPfU4T124HEqWPI3P4z8GVSE vgKkvhvGoJAqKF+042GApJhZ+iIU66w== X-Google-Smtp-Source: AGHT+IEW+dNm9DrE899rVHYWAmHVKVBqefEvD3q7UkSgaXoil66nEVWAeJ01zxHAJFF6/38xtj0OFwFFAhyA3VwKn/A= X-Received: by 2002:a05:6870:a690:b0:24c:4e2f:9a55 with SMTP id 586e51a60fabf-24c68d7be47mr3104962fac.22.1716406721365; Wed, 22 May 2024 12:38:41 -0700 (PDT) MIME-Version: 1.0 References: <4165841.1716397819@sss.pgh.pa.us> In-Reply-To: From: Ron Johnson Date: Wed, 22 May 2024 15:38:30 -0400 Message-ID: Subject: Re: search_path and SET ROLE To: pgsql-general Content-Type: multipart/alternative; boundary="000000000000eaccbb06191014d7" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000eaccbb06191014d7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. An= d 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. --000000000000eaccbb06191014d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, May 22, 2024 at 2:02=E2=80=AFPM I= saac Morland <isaac.morland@g= mail.com> wrote:
On Wed= , 22 May 2024 at 13:48, Ron Johnson <ronljohnsonjr@gmail.com> wrote:
<= div class=3D"gmail_quote">

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

\dt *.*

Also shows information_schema, pg_catalog, and pg_t= oast.=C2=A0 I can adjust to that, though.
=C2=A0
But I am skeptical how often you really want this i= n a real database with more than a few tables. Surely \dn+ followed by \dt = [schemaname].* for a few strategically chosen [schemaname] would be more us= eful?

More than you&#= 39;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 schem= a they're in.

--000000000000eaccbb06191014d7--