Date: Tue, 7 May 2019 18:58:24 -0400
From: Stephen Frost <sfrost@snowman.net>
To: David Fetter <david@fetter.org>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>,
	PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: New EXPLAIN option: ALL
Message-ID: <20190507225824.GQ6197@tamriel.snowman.net>
References: <20190507073046.GI28936@fetter.org>
 <20190507154147.l32a3erg4mbycj7u@alap3.anarazel.de>
 <20190507163411.GM28936@fetter.org>
 <20190507164430.a7tig676hjzdnyyd@alap3.anarazel.de>
 <20190507212355.GQ28936@fetter.org>
 <20190507215449.3a4yb5kkoloq7yyw@alap3.anarazel.de>
 <4638.1557266803@sss.pgh.pa.us>
 <20190507221255.GO6197@tamriel.snowman.net>
 <20190507223900.GR28936@fetter.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="INBqYDgoWIi7NvYt"
Content-Disposition: inline
In-Reply-To: <20190507223900.GR28936@fetter.org>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk


--INBqYDgoWIi7NvYt
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Greetings,

* David Fetter (david@fetter.org) wrote:
> On Tue, May 07, 2019 at 06:12:56PM -0400, Stephen Frost wrote:
> > * Tom Lane (tgl@sss.pgh.pa.us) wrote:
> > > One idea that comes to mind is that VERBOSE could be redefined as
> > > some sort of package of primitive options, including all of the
> > > "additional information" options, with the ability to turn
> > > individual ones off again if you wanted.  So for example (VERBOSE,
> > > BUFFERS OFF) would give you everything except buffer stats.  We'd
> > > need a separate flag/flags to control what VERBOSE originally did,
> > > but that doesn't bother me --- it's an opportunity for more
> > > clarity of definition, anyway.
> >=20
> > I'm generally in favor of doing something like what Tom is
> > suggesting with VERBOSE, but I also feel like it should be the
> > default for formats like JSON.  If you're asking for the output in
> > JSON, then we really should include everything that a flag like
> > VERBOSE would contain because you're pretty clearly planning to
> > copy/paste that output into something else to read it anyway.
>=20
> So basically, every format but text gets the full treatment for
> (essentially) the functionality I wrapped up in ALL?  That makes a lot
> of sense.

Something along those lines is what I was thinking, yes, and it's what
at least some other projects do (admittedly, that's at least partially
my fault because I'm thinking of the 'info' command for pgbackrest, but
David Steele seemed to think it made sense also, at least).

> > I'm all in favor of adding an alias for analyze called 'execute', as
> > that makes a lot more sense and then updating our documentation to
> > use it, with 'analyze is accepted as an alias' as a footnote.
>=20
> How about making ANALYZE a backward-compatibility feature in the sense
> of replacing examples, docs, etc., with EXECUTE? If most of our users
> are in the future, this makes those same users's better without
> qualification, and helps some positive fraction of our current users.

I'd rather not refer to it as a backwards-compatibility feature since
we, thankfully, don't typically do that and I generally think that's the
right way to go- but in some cases, like this one, having a 'legacy'
spelling or an alias seems to be darn near free without opening the box
of trying to provide backwards compatibility for everything.

> On a slightly related topic, we haven't, to date, made any promises
> about what EXPLAIN will put out, but as we make more machine-readable
> versions, we should at least think about its schema and versioning
> of same.

Not really sure that I agree on this point.  Do you see a reason to need
versioning or schema when the schema is, essentially, included in each
result since it's JSON or the other machine-readable formats?  I can
imagine that we might need a version if we decided to redefine some
existing field in a non-compatible or non-sensible way, but is that
possibility likely enough to warrent adding versioning and complicating
everything downstream?  I have a hard time seeing that.

Thanks,

Stephen

--INBqYDgoWIi7NvYt
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJc0g2QAAoJEO1sijiDR2RV784P/Rtlj0aoRRokAtcoj18b6xTb
sKzwNzAoHT9aJq217N89zke8UxCBBgguMxc1W/c1vUzDBC3fMuja/fdsSDhOFkEB
uiZ8XP18NlVEJDUOrGM2m7VjA5/ee4gQVxlat/nVoqqxjV137mU90i3GBVVKjFM9
LgLdXalW2j8sRjFkNhBaRZmVb9IQVSHRX+6lwc5sfYbT/1GBM2AnWvW4bhquvN3Q
An6x2ovWSsNiSggogP55g7Xb82Rrq/Q4tZmT8vB2fkjiNcEVCngZ2UbiXX7D0X9q
hnmyHD6k5TSyyO87oYY9jwJ+PUOvmVlvTY8m2xsw8Eiw+d1zB2MzpEeKsM9ijmWX
2Z/pI7MtEGlwWBchP58dKHKkMU62tlf1DxwUQ8FlL/GkBVTDEHvv4Q6cNw3b+7BQ
h5dtr4zVbQH3EoLNru+iCqYLMkeGgJQ7gsJAIZiOQWLJf5TC6MqXSDLki9wn/sWU
Pr5GM/hcW73xqZJnmkpQySof4XQIRuIO3SIt/n4Av4sMMY2Op9l9hkS8675cKEHJ
xn33KkO3nQ8Y8s/ov+2y5PWUaW113a9zt0ZUnFtzOhQXnKMmwh+tT9rohe+VRoSj
4VjD9IAYku/JJLGGwnuwXbK7SzxwrTJwvHIUGGW3PpNnnp1PzPhN59TjVj2uWgwI
9Y3TRfsOw1SiLo7YfJhi
=UGW7
-----END PGP SIGNATURE-----

--INBqYDgoWIi7NvYt--