On 2017/08/01 11:44, David G. Johnston wrote:
> On Mon, Jul 31, 2017 at 7:06 PM, Robert Haas <robertmh...@gmail.com> wrote:
> 
>> On Thu, Jul 13, 2017 at 8:40 PM, Amit Langote
>> <langote_amit...@lab.ntt.co.jp> wrote:
>>> On 2017/07/13 19:57, Ashutosh Bapat wrote:
>>>> On Thu, Jul 13, 2017 at 12:01 PM, Amit Langote
>>>> <langote_amit...@lab.ntt.co.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



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to