On Wed, Jul 29, 2020 at 03:21:19PM +0900, Michael Paquier wrote:
> On Wed, Jul 29, 2020 at 01:27:07PM +0900, Masahiko Sawada wrote:
> > Good catch. The patch looks good to me.
>
> While this patch is logically correct. I think that we should try to
> not increase more the number of queries used to scan pg_class
> depending on a list of relkinds. For example, did you notice that
> your new Query_for_list_of_vacuumables becomes the same query as
> Query_for_list_of_indexables? You can make your patch more simple.
I didn't notice. There's an argument for keeping them separate, but as long as
there's a #define in between, this is fine, too.
On Wed, Jul 29, 2020 at 08:05:57PM +0900, Michael Paquier wrote:
> On Wed, Jul 29, 2020 at 06:41:16PM +0900, Masahiko Sawada wrote:
> > whereas Query_for_list_of_vacuumables should search for:
> >
> > RELKIND_RELATION
> > RELKIND_PARTITIONED_TABLE
> > RELKIND_MATVIEW
> > RELKIND_TOASTVALUE
>
> FWIW, I don't think that we should make toast relations suggested to
> the user at all for any command. This comes down to the same point
> that we don't have pg_toast in search_path, and going down to this
> level of operations is an expert-level mode, not something we should
> recommend to the average user in psql IMO.
Right. Tom's response to that suggestion a couple years ago I thought was
pretty funny (I picture Dr. Claw at his desk using psql tab completion being
presented with a list of pg_toast.pg_toast_NNNNNN OIDs: "which TOAST table
should I vacuum next..")
https://www.postgresql.org/message-id/14255.1536781...@sss.pgh.pa.us
|I don't actually think that's a good idea. It's more likely to clutter
|peoples' completion lists than offer anything they want. Even if someone
|actually does want to vacuum a toast table, they are not likely to be
|entering its name via tab completion; they're going to have identified
|which table they want via some query, and then they'll be doing something
|like copy-and-paste out of a query result.
--
Justin
>From c5b356797fc092aec076cca9faa83ea086516350 Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryz...@telsasoft.com>
Date: Tue, 28 Jul 2020 11:56:26 -0500
Subject: [PATCH v2] Tab completion for VACUUM of partitioned tables
---
src/bin/psql/tab-complete.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c
index 272f799c24..b464aceea4 100644
--- a/src/bin/psql/tab-complete.c
+++ b/src/bin/psql/tab-complete.c
@@ -573,8 +573,11 @@ static const SchemaQuery Query_for_list_of_indexables = {
.result = "pg_catalog.quote_ident(c.relname)",
};
-/* Relations supporting VACUUM */
-static const SchemaQuery Query_for_list_of_vacuumables = {
+/* Relations supporting VACUUM are currently same as those supporting indexing */
+#define Query_for_list_of_vacuumables Query_for_list_of_indexables
+
+/* Relations supporting CLUSTER */
+static const SchemaQuery Query_for_list_of_clusterables = {
.catname = "pg_catalog.pg_class c",
.selcondition =
"c.relkind IN (" CppAsString2(RELKIND_RELATION) ", "
@@ -584,9 +587,6 @@ static const SchemaQuery Query_for_list_of_vacuumables = {
.result = "pg_catalog.quote_ident(c.relname)",
};
-/* Relations supporting CLUSTER are currently same as those supporting VACUUM */
-#define Query_for_list_of_clusterables Query_for_list_of_vacuumables
-
static const SchemaQuery Query_for_list_of_constraints_with_schema = {
.catname = "pg_catalog.pg_constraint c",
.selcondition = "c.conrelid <> 0",
--
2.17.0
