Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pDxCm-0003Cz-43 for pgsql-hackers@arkaria.postgresql.org; Sat, 07 Jan 2023 00:37:00 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pDxCk-0006EM-VS for pgsql-hackers@arkaria.postgresql.org; Sat, 07 Jan 2023 00:36:58 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pDxCk-0006EC-Ku for pgsql-hackers@lists.postgresql.org; Sat, 07 Jan 2023 00:36:58 +0000 Received: from mail-pj1-x1030.google.com ([2607:f8b0:4864:20::1030]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pDxCh-0002e3-Sw for pgsql-hackers@postgresql.org; Sat, 07 Jan 2023 00:36:58 +0000 Received: by mail-pj1-x1030.google.com with SMTP id o7-20020a17090a0a0700b00226c9b82c3aso3517299pjo.3 for ; Fri, 06 Jan 2023 16:36:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=0gqRiaKtoEFLNKFHkVfU90m8PqGny8c0SYJijh6AQCY=; b=RkkfwREcmM0I+8LN4ZNdEQUj00w/RCJEBni/PQY3c1TUg7/jrEK5HekmKnRqitg89S wI/juz1gPEUkX/7HBZO83RCkcubgm4kxQb5bKMUHs3DLmZEnQWnnHJqE86UzTtjkNhCo ohmzutRF2Xb70oFfD1L+ttfFDbd69iggcoFHBOHvu5RttlaXqG+HD/cgIS8lqiZu6Jte pswW7xb+cq+mxJtmqvghhJRZgmRYyBrx2G7mGpMWKu5tBufjZrZjtS08hW0kKlp+IWDx 8cl5le2kGN/HCe1xt/F8BHSZBP7i+W5BlMUyQsOtpbIYZjEbKfFUlN/AC07UJxvRRKK+ kNPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=0gqRiaKtoEFLNKFHkVfU90m8PqGny8c0SYJijh6AQCY=; b=KQMNkKCQu5tcOEMlPMnLPrhUKOm3rbW0gddD4djmanWkyUNhUIUhcV201WHxBjl3SL Qua/MYvxwmdJ15KTiNepM2XzAOm9kygg5Ghd8ygrjhv8ulGqtyvs60PL1PUmUQchztNg cgYX6QtujtbJbhVgj8sRKymitKxisflkJBe5X1aTsuwOIoyfR+xQnkmzlOtLt/Ml/IiH AcvyK988p9arC5IlEDfXTtMZXMhdScmhHU+CaLAZ7rerWTNmDZ4JMBMYm97S1ia3LMlf XHKqMufcD6PmRtwmpXDS+IYPCfcf1BflDgK05fCQQGBO3IA4IhlP/bXHe9DMD1v8BVv9 j2Dg== X-Gm-Message-State: AFqh2krPQcc/fIUBgHIl2o6RpXot5aROTofAnXHVuLs+jq18sadpHXmw 6Yn7+E5lYt6RxHUAun38BXIB8uE8z5Y= X-Google-Smtp-Source: AMrXdXvoIGWODfC8O/7J3N73ygf15LjgeY87jLDZd2FovBd0qWjxuWM3pygBjmOSwn6yVV4pbEXzWg== X-Received: by 2002:a17:902:8a82:b0:192:8c85:54fa with SMTP id p2-20020a1709028a8200b001928c8554famr38578967plo.31.1673051813619; Fri, 06 Jan 2023 16:36:53 -0800 (PST) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id q11-20020a170902eb8b00b00189c93ce5easm1475106plg.166.2023.01.06.16.36.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Jan 2023 16:36:52 -0800 (PST) Date: Fri, 6 Jan 2023 16:36:51 -0800 From: Nathan Bossart To: Dean Rasheed Cc: Maxim Orlov , Andrew Dunstan , Michael Paquier , Tom Lane , Isaac Morland , Justin Pryzby , Pavel Luzanov , pgsql-hackers@postgresql.org Subject: Re: add \dpS to psql Message-ID: <20230107003651.GA789289@nathanxps13> References: <45224.1670476523@sss.pgh.pa.us> <20221208171503.GA2113@nathanxps13> <20221209184055.GA59417@nathanxps13> <20221209184411.GB59417@nathanxps13> <09d09155-7ed0-29e2-c51b-e5cce7e68bf0@dunslane.net> <20221212171822.GA202606@nathanxps13> <20221228212612.GA4010186@nathanxps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, Jan 06, 2023 at 06:52:33PM +0000, Dean Rasheed wrote: > Looking this over this, I have a couple of comments: Thanks for reviewing. > Firstly, I think it should allow \zS in the same fashion as \dpS, > since \z is an alias for \dp, so the 2 should be kept in sync. That seems reasonable to me. > Secondly, I don't think the following is the right SQL clause to use > in the absence of "S": > > if (!showSystem && !pattern) > appendPQExpBufferStr(&buf, "AND n.nspname !~ '^pg_'\n"); > > I know that's the condition it used before, but the problem with using > that now is that it will cause temporary relations to be excluded > unless the "S" modifier is used, which goes against the expectation > that "S" just causes system relations to be included. Also, it fails > to exclude information_schema relations, if that happens to be on the > user's search_path. > > So I think we should use the same SQL clauses as every other psql > command that supports "S", namely: > > if (!showSystem && !pattern) > appendPQExpBufferStr(&buf, " AND n.nspname <> 'pg_catalog'\n" > " AND n.nspname <> 'information_schema'\n"); Good catch. I should have noticed this. The deleted comment mentions that the system/temp tables normally aren't very interesting from a permissions perspective, so perhaps there is an argument for always excluding temp tables without a pattern. After all, \dp always excludes indexes and TOAST tables. However, it looks like \dt includes temp tables, and I didn't see any other meta-commands that excluded them. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com