Re: psql's \d versus included-index-column feature
On Thursday, July 19, 2018, Tom Lane wrote: > > > 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. > > WFM, anyone want to argue against? > Works for me as well. David J.
Re: psql's \d versus included-index-column feature
Oleksandr Shulgin writes: > 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. WFM, anyone want to argue against? regards, tom lane
Re: psql's \d versus included-index-column feature
On Thu, Jul 19, 2018 at 1:11 AM Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > On Wed, Jul 18, 2018 at 11:14 PM David G. Johnston < > david.g.johns...@gmail.com> wrote: > >> On Wed, Jul 18, 2018 at 12:55 PM, Tom Lane 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
Re: psql's \d versus included-index-column feature
On Wed, Jul 18, 2018 at 11:14 PM David G. Johnston < david.g.johns...@gmail.com> wrote: > On Wed, Jul 18, 2018 at 12:55 PM, Tom Lane 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. -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
Re: psql's \d versus included-index-column feature
On 2018-Jul-18, Tom Lane wrote: > I can sympathize with the eyestrain argument against t/f, but the > above doesn't seem like an improvement --- in particular, "Data" > as the column header seems quite content-free. My counterproposal > is to keep "Key" as the header and use "Yes"/"No" as the values. I think "Key: no" is a bit obscure -- using "included" is a bit more self-documenting and lends better to documentation searches. > I'd be OK with "Key"/"Included" as the values if someone can > propose an on-point column header to go with those. "Role"? -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: psql's \d versus included-index-column feature
Alvaro Herrera writes: > On 2018-Jul-18, David G. Johnston wrote: >> -1 for printing a boolean t/f; would rather spell it out: >> >> CASE WHEN "Key" THEN 'Key' ELSE 'Included' END AS "Data" > +1 I can sympathize with the eyestrain argument against t/f, but the above doesn't seem like an improvement --- in particular, "Data" as the column header seems quite content-free. My counterproposal is to keep "Key" as the header and use "Yes"/"No" as the values. I'd be OK with "Key"/"Included" as the values if someone can propose an on-point column header to go with those. regards, tom lane
Re: psql's \d versus included-index-column feature
On 2018-Jul-18, David G. Johnston wrote: > -1 for printing a boolean t/f; would rather spell it out: > > CASE WHEN "Key" THEN 'Key' ELSE 'Included' END AS "Data" +1 -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: psql's \d versus included-index-column feature
On Wed, Jul 18, 2018 at 12:55 PM, Tom Lane 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 for printing a boolean t/f; would rather spell it out: CASE WHEN "Key" THEN 'Key' ELSE 'Included' END AS "Data" We're not hurting for horizontal space here and in any case I'd rather save others the eye strain of having to distinguish between lowercase "f" and "t". David J.
