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

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

> On Wed, Jul 18, 2018 at 11:14 PM David G. Johnston <
> david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>
>> On Wed, Jul 18, 2018 at 12:55 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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