Re: make \d pg_toast.foo show its indices
От | Robert Haas |
---|---|
Тема | Re: make \d pg_toast.foo show its indices |
Дата | |
Msg-id | CA+TgmoY5LWi2YOZozfv1mrZFD7exMKs_guLP0NgJC=o2xCpe8Q@mail.gmail.com обсуждение исходный текст |
Ответ на | 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 |
On Tue, May 7, 2019 at 6:03 PM Stephen Frost <sfrost@snowman.net> wrote: > Alright, maybe I'm not the best representation of our user base, but I > sure type 'select oid,* from pg_class where relname = ...' with some > regularity, mostly to get the oid to then go do something else. Having > the relfilenode would be nice too, now that I think about it, and > reltuples. There's ways to get *nearly* everything that's in pg_class > and friends out of various \d incantations, but not quite everything, > which seems unfortunate. > > In any case, I can understand an argument that the code it requires is > too much to maintain for a relatively minor feature (though it hardly > seems like it would be...) or that it would be confusing or unhelpful to > users (aka "noise") much of the time, so I'll leave it to others to > comment on if they think any of these ideas be a useful addition or not. > > I just don't think we should be voting down a feature because it'd take > a bit of extra effort to make our regression tests work with it, which > is all I was intending to get at here. I think it's unjustifiable to show this in \d output. But maybe in \d+ output it could be justified, or perhaps in the \d++ which I seem to recall Alvaro proposing someplace recently. I think if we're going to show it, it should be on its own line, with a clear label, not just in the table header as you proposed. Otherwise, people won't know what it is. I suppose the work we'd need to make it work with the regression tests is no worse than the hide_tableam crock which Andres recently added. That is certainly a crock, but I can testify that it's a very useful crock for zheap development. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: