Relations are a super-class of table-things. There are many subtypes of relations. \d Lists relations of all subtypes. You can also add a single letter to \d to limit the listing to only the subtype-specific relations. That is what the E is doing here.
That's an obtuse answer. If everything is "a table thing", why even bother printing a title? Normally, select() doesn't show a title, so if you're just going to dump data to the screen with misleading titles, why bother with a garbage title? And how is \di, list indexes "table things"? You can't select from an index, so for users they're not relations.
You can quibble with our definitions but they probably aren't going to change (and a bug report isn't the best place to try anyway). The glossary says:
Relation
The generic term for all objects in a database that have a name and a list of attributes defined in a specific order. Tables, sequences, views, foreign tables, materialized views, composite types, and indexes are all relations.
More generically, a relation is a set of tuples; for example, the result of a query is also a relation.
And the design methodology given extends from that.
It seems to be another list of foreign tables but with a different format.
Since \d can only show information limited to the super-class relation, and not specific subtypes, the information for the foreign table subtype needs to be made available somewhere. That place is \det
I don't know what that means, but when two menu items have the same text, but a different function, Houston, we have a problem.
I agree with this premise. It's still a matter of R&D to find the violation and fix them - without confounding things with also tryIng to declassify indexes as relations.
