Re: make \d pg_toast.foo show its indices
От | Tom Lane |
---|---|
Тема | Re: make \d pg_toast.foo show its indices |
Дата | |
Msg-id | 30641.1557242690@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: make \d pg_toast.foo show its indices (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: make \d pg_toast.foo show its indices
|
Список | pgsql-hackers |
Stephen Frost <sfrost@snowman.net> writes: > * Tom Lane (tgl@sss.pgh.pa.us) wrote: >> Rafia Sabih <rafia.pghackers@gmail.com> writes: >>> IMHO, what makes more sense is to show the name of associated toast >>> table in the \dt+ of the normal table. >> I'm not for that: it's useless information in at least 99.44% of cases. > I don't think I'd put it in \dt+, but the toast table is still > pg_toast.pg_toast_{relOid}, right? What about showing the OID of the > table in the \d output, eg: > => \d comments > Table "public.comments" (50788) Not unless you want to break every regression test that uses \d. Instability of the output is also a reason not to show the toast table's name in the parent's \d[+]. >> Possibly it is useful in the other direction as Justin suggests. >> Not sure though --- generally, if you're looking at a specific >> toast table, you already know which table is its parent. But >> maybe confirmation is a good thing. > As mentioned elsewhere, there are certainly times when you don't know > that info and if you're looking at the definition of a TOAST table, > which isn't terribly complex, it seems like a good idea to go ahead and > include the table it's the TOAST table for. I'm not against putting that info into the result of \d on the toast table. regards, tom lane
В списке pgsql-hackers по дате отправления: