Re: [PATCH] Tab completion for VACUUM of partitioned tables

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.1536781029@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