Re: allow to \dtS+ pg_toast.* - Mailing list pgsql-hackers

From Justin Pryzby
Subject Re: allow to \dtS+ pg_toast.*
Date
Msg-id 20201218065808.GY30237@telsasoft.com
Whole thread Raw
In response to Re: allow to \dtS+ pg_toast.*  (Laurenz Albe <laurenz.albe@cybertec.at>)
Responses Re: allow to \dtS+ pg_toast.*
List pgsql-hackers
Thanks for looking

On Thu, Dec 17, 2020 at 04:16:52PM +0100, Laurenz Albe wrote:
> On Mon, 2020-11-30 at 10:54 -0600, Justin Pryzby wrote:
> > This makes toast tables a bit less special and easier to inspect.
> > 
> > postgres=# \dtS+ pg_toast.pg_toast_2619
> >  pg_toast | pg_toast_2619 | toast table | pryzbyj | permanent   | heap          | 56 kB | 
> > 
> > This follows commit from last year:
> > | eb5472da9 make \d pg_toast.foo show its indices ; and, \d toast show its main table
> 
> This would indeed be convenient.
> 
> While playing around with it, I found the following oddity:
> 
> regression=# \dtS pg_toast.pg_toast_30701
>  pg_toast | pg_toast_30701 | toast table | laurenz
> 
> regression=# \dt pg_toast.pg_toast_30701
> Did not find any relation named "pg_toast.pg_toast_30701".
> 
> Now this doesn't seem right.  To my understanding, \dtS should do the same as \dt,
> except that it should also search in "pg_catalog" if no schema was provided.

You mean that if pg_toast.* should be shown if a matching "pattern" is given,
even if "S" was not used.  I think you're right.  The behavior I implemented
was intended to provide a bit of historic compatibility towards hiding toast
tables, but I think it's not needed, since they're not shown anyway unless
someone includes "S", specifies the "pg_toast." schema, or pg_toast is in their
search path.  See attached.

> Another thing that is missing is tab completion for
> regression=# \dtS pg_toast.pg_
> This should work just like for \d and \dS.

Tom objected to this in the past, humorously to me:

https://www.postgresql.org/message-id/14255.1536781029@sss.pgh.pa.us
On Wed, Sep 12, 2018 at 03:37:09PM -0400, Tom Lane wrote:
> Arthur Zakirov <a.zakirov@postgrespro.ru> writes:
> > On Sun, Jul 29, 2018 at 07:42:43PM -0500, Justin Pryzby wrote:
> >>> Actually..another thought: since toast tables may be VACUUM-ed, should I
> >>> introduce Query_for_list_of_tpmt ?
> 
> >> I didn't include this one yet though.
> 
> > I think it could be done by a separate patch.
> 
> 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.

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Refactoring HMAC in the core code
Next
From: Michael Paquier
Date:
Subject: Incorrect allocation handling for cryptohash functions with OpenSSL