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
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
> +-
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 "publi
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
>> +-+-
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 val
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 improve
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 & Servi
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 | c
I noticed that psql's \d command doesn't do very well with included
index columns. Given the regression db's test case,
CREATE INDEX tbl_include_reg_idx ON tbl_include_reg (c1, c2) INCLUDE (c3, c4);
we get
regression=# \d tbl_include_reg_idx
Index "public.tbl_include_reg_idx"
Column | Type
