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

Поиск
Список
Период
Сортировка
От Oleksandr Shulgin
Тема Re: psql's \d versus included-index-column feature
Дата
Msg-id CACACo5Si9=k=jYodyRD9ykzBjSki2h6-=sbR-YSTYu6EpPKBXQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: psql's \d versus included-index-column feature  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Ответы Re: psql's \d versus included-index-column feature
Список pgsql-hackers
Дерево обсуждения
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

В списке pgsql-hackers по дате отправления: