Re: Update description of \d[S+] in \?

On 2017/08/01 11:44, David G. Johnston wrote:
> On Mon, Jul 31, 2017 at 7:06 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
>> On Thu, Jul 13, 2017 at 8:40 PM, Amit Langote
>> <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>>> On 2017/07/13 19:57, Ashutosh Bapat wrote:
>>>> On Thu, Jul 13, 2017 at 12:01 PM, Amit Langote
>>>> <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>>>>> The description of \d[S+] currently does not mention that it will list
>>>>> materialized views and foreign tables. Attached fixes that.
>>>>>
>>>>
>>>> I guess the same change is applicable to the description of \d[S+] NAME
>> as well.
>>>
>>> Thanks for the review. Fixed in the attached.
>>
>> The problem with this, IMV, is that it makes those lines more than 80
>> characters, whereas right now they are not.
>
>
> ​84: ​ \\d[S+] list (foreign) tables, (materialized)
> views, and sequences\n
> 76: \\d[S+] list (foreign) tables, (mat.) views, and
> sequences\n
>
> And that line seems
>> doomed to get even longer in the future.
>>
>
> ​Cross that bridge when we come to it?
>
> Lumping the tables and views into a single label (I'd go with "relations"
> since these are all - albeit non-exclusively - things that can appear in a
> FROM clause) would greatly aid things here. Indexes and sequences would
> retain their own identities. But I seem to recall that elsewhere we call
> indexes relations - and I'm not sure about sequences.
>
> I'm partial to calling it "relations and sequences" and letting the reader
> check the documentation for what "relations" means in this context.

Hmm, that makes it short.

\d[S+] list relations and sequences
\d[S+] NAME describe relation, index, or sequence

But, quite a few error messages generated by the backend will still list
them with the current names that are based on relkind. For example, here
is one:

alter table foo_a_seq rename last_value to what;

ERROR: "foo_a_seq" is not a table, view, materialized view, composite
type, index, or foreign table

Any terminology change we introduce will have to preserve consistency
across the board.

Thanks,
Amit