Date: Sun, 6 Sep 2020 15:48:23 -0500
From: Justin Pryzby <pryzby@telsasoft.com>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>,
	Georgios Kokolatos <gkokolatos@pm.me>,
	PostgreSQL Hackers <pgsql-hackers@postgresql.org>,
	Tomas Vondra <tomas.vondra@2ndquadrant.com>,
	Tatsuro Yamada <tatsuro.yamada.tf@nttcom.co.jp>
Subject: Re: v13: show extended stats target in \d
Message-ID: <20200906204823.GC6744@telsasoft.com>
References: <20200901011429.GZ5450@telsasoft.com>
 <20200901210825.GA20170@alvherre.pgsql>
 <CAH2-Wzn+KVrpMTLA=uq0E+t866uH_Tbfp_NGW9pf1muBZ=cAMQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAH2-Wzn+KVrpMTLA=uq0E+t866uH_Tbfp_NGW9pf1muBZ=cAMQ@mail.gmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Precedence: bulk

On Sun, Sep 06, 2020 at 01:06:05PM -0700, Peter Geoghegan wrote:
> On Tue, Sep 1, 2020 at 2:08 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> > It does need some separator.  Maybe a comma is sufficient, but I'm not
> > sure: that will fail when we add cross-relation stats, because the
> > FROM clause will have more relations and possibly have commas too.
> 
> How about a line break? That seems like a simple solution that takes
> all the competing concerns into account.
> 
> The fact that that will stand out isn't necessarily a bad thing. I
> think it's a good thing.

Like this ?

postgres=# \d t  
                 Table "public.t"
 Column |  Type   | Collation | Nullable | Default
--------+---------+-----------+----------+---------
 a      | integer |           |          |
 b      | integer |           |          |
Statistics objects:
    "public"."t" (ndistinct, dependencies, mcv) ON a, b FROM t

Are there any other examples of similarly related information spread across
lines ?

I find that to be too verbose ; I guess it could be shown only in \d+, which is
true of column stats.

It's weird that the quoting rules are different for the stats object vs the
columns and the table.  The schema qualification is also divergent.  Also,
"public.t" form is technically wrong (the objects should be *separately*
quoted), but seems to be used all over.  If the table or schema has a dot, it's
ambiguous what this means: Table "public.public.t".

-- 
Justin