Re: psql's \d versus included-index-column feature

On Thu, Jul 19, 2018 at 1:11 AM Alexander Korotkov <
a.korotkov@postgrespro.ru> wrote:

> On Wed, Jul 18, 2018 at 11:14 PM David G. Johnston <
> david.g.johnston@gmail.com> wrote:
>
>> On Wed, Jul 18, 2018 at 12:55 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>
>>>
>>> regression=# \d tbl_include_reg_idx
>>> Index "public.tbl_include_reg_idx"
>>>  Column |  Type   | Key | Definition
>>> --------+---------+------------------
>>>  c1     | integer | t   | c1
>>>  c2     | integer | t   | c2
>>>  c3     | integer | f   | c3
>>>  c4     | box     | f   | c4
>>> btree, for table "public.tbl_include_reg"
>>>
>>
>> ​+1 for the additional column indicating whether the column is being
>> treated as key data or supplemental included data.​
>>
>
> +1
> And especially I don't think we should place word "INCLUDE" to the
> definition column.
>
> ​-1 for printing a boolean t/f; would rather spell it out:
>>
>
> IMHO, t/f have advantage of brevity.  From my point of view, covering
> indexes are not so evident feature.  So, users need to spend some time
> reading documentation before realizing what they are and how to use them.
> So, I don't expect that short designation of INCLUDE columns as "non-key"
> (Key == false) columns could be discouraging here.
>

I don't think there is an established practice on how to display this sort
of info, but I see that both styles already exist, namely:

=# \dL
                       List of languages
    Name    |  Owner   | Trusted |         Description
------------+----------+---------+------------------------------
 plpgsql    | postgres | t       | PL/pgSQL procedural language
 plproxy    | postgres | f       |
...

and

=# \dC
                                         List of casts
         Source type         |         Target type         |      Function
    |   Implicit?
-----------------------------+-----------------------------+--------------------+---------------
 abstime                     | date                        | date
     | in assignment
 abstime                     | integer                     | (binary
coercible) | no
 abstime                     | timestamp without time zone | timestamp
    | yes
...

I like the second option more, for readability reasons and because it is
easier to extend if ever needed.

Given that the documentation refers to included columns as "non-key
columns", it seems natural to me to name the \d output column "Key?" and
use "yes/no" as the values.

Regards,
--
Alex