Date: Mon, 30 Jan 2017 10:35:33 -0500
From: Stephen Frost <sfrost@snowman.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Pavel Stehule <pavel.stehule@gmail.com>,
	Christoph Berg <christoph.berg@credativ.de>,
	Daniel Verite <daniel@manitou-mail.org>,
	PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: One-shot expanded output in psql using \G
Message-ID: <20170130153532.GE9812@tamriel.snowman.net>
References: <20170127132737.6skslelaf4txs6iw@msg.credativ.de>
 <74e7fd23-f5a9-488d-a8c4-1e0da674b27c@manitou-mail.org>
 <20170130101424.fo4knpn4blaohazk@msg.df7cb.de>
 <20170130134608.GA9812@tamriel.snowman.net>
 <CAFj8pRDLr=exBc4QZg7POLZcGHNi539ibhVqmGzWctyPo0TZ7A@mail.gmail.com>
 <20170130150458.GC9812@tamriel.snowman.net>
 <24326.1485789276@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="eegVCDMvnUS/vTOg"
Content-Disposition: inline
In-Reply-To: <24326.1485789276@sss.pgh.pa.us>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


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

Tom,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > This particular bike-shedding really doesn't seem to be terribly useful
> > or sensible, to me.  \gx isn't "consistent" or "descriptive", frankly.
>=20
> Why not?  To me it reads as "\g with an x option".  The "x" refers to
> the implied "\x", so it's not an arbitrary choice at all.

That's not how '\dx' works, as I pointed out, so I don't see having the
second character being 'x' to imply "\x mode" makes sense.

Further, as it relates to formatting, "\x mode" is, far and away in my
experience, the only regularly used alternative formatting in
interactive psql sessions.

I can't recall ever using the other formatting toggles (aligned, HTML,
and tuples only) before in interactive sessions, except (rarely) with
\o.  I tend to think we've got them primairly to provide the same
options that we have at the command-line, which can be handy, but not
because I'm very often going to want to flip between aligned and
unaligned mode while querying tables.

> The main problem I see with \G is that it's a dead end.  If somebody
> comes along next year and says "I'd like a variant of \g with some other
> frammish", what will we do?  There are no more case variants to use.

I don't believe there's any reason to think someone else couldn't come
along later and add \gq for whatever they want.  Simply because we use
\G for something doesn't mean \g can't ever be further extended.

> In short, really the direction this ought to go in is \g[options] [file]
> which is perfectly consistent with precedents in psql such as \d.
> But there isn't any place where we've decided that upper case means
> a variant of a lower case command.

I agree that we don't currently have a case that upper case means a
variant of a lower case command, but I'm not arguing that we do.

We do have cases where various \d sub-commands end up being very
different things depending on if it's a lower-case letter or an
upper-case letter, but that doesn't imply, to me at least, that every
use of an upper-case letter must be completely different from what the
lower-case letter is for.

Obviously, I'd like to have this and if enough people think that the
right answer is '\gx', then so be it, but I don't buy the consistency
argument and without actual consistency across commands which take 'x'
as a sub-command I don't see the 'descriptive' argument as holding much
weight either.

Thanks!

Stephen

--eegVCDMvnUS/vTOg
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

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

iQIcBAEBCgAGBQJYj11EAAoJEO1sijiDR2RV+W4P/iBFyLcnD0Jz7B66/9ZfvD23
qoN5FqweI1YroqmLroRkfyY9hGemuR0xzIX7yyjjR5nABB3V7x12jKL+zg3FhHfh
6a83ID+4qFh1ZJk+TErN6kr1db9uk22FABUedp9j5iF2+HqWVdfgfEaa2BMseRMs
JAVVnf6OW913bj3fVeRiGegxx5LwVRCt1bNo1JD3UeLzhS7cO2tbqLjTuzXDcgFi
zEjwCmakgPCcbrroNoqwSyDXDECCoO8PNJb55kbO7TSBGXQ2PBbYT7om6pJ0zO7W
dUGUIUtioN80Ray0/SkPHCR5ohoEHLlkaiHLLO2k1KWRvVk+KgzCDp7Yp9BuUgl3
5sGDtlXax7UsBju6b/sk7gBZJJOF3b/qS7mh9qbs6h5VJpB526NqlZaB4MRr4gMg
IrObDXGPn1Y+JXiBu7sDL7SAkhjV5E3UcSfpWt2ZECPq5XReobR0fHQJPioDAuai
C97DsK053tuaGPumj3VsXEVtDz2/jtL4LriPd8ylM8XpNza+uS3pJ0jC/+x9BH/a
Rlnx0yDIMfdPvesDmISMeHnMIWFJpTBflxfOLuGV8jsc1bHedEt/h/iHxd9Y1DXY
eOf8eu31urKGJCvHvK2oQ0q/K/YWSLXIQ/gSbkUOgBn/4CUWKqj1sD1jChOi5hz6
UViPrr3YGx9UE/xj4XUz
=J3J4
-----END PGP SIGNATURE-----

--eegVCDMvnUS/vTOg--