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:
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.
