Re: psql: add \pset true/false
Pavel Stehule <pavel.stehule@gmail.com>
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Matthijs van der Vleuten <matthijs@zr40.nl>
Cc: Brendan Jurd <direvus@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>,
Marko Tiikkaja <marko@joh.to>, Daniel Verite <daniel@manitou-mail.org>,
PostgreSQL hackers <pgsql-hackers@postgresql.org>
Date: 2015-11-12T17:10:46Z
Lists: pgsql-hackers
2015-11-12 17:41 GMT+01:00 Matthijs van der Vleuten <matthijs@zr40.nl>: > > On 12 Nov 2015, at 14:21, Brendan Jurd <direvus@gmail.com> wrote: > > On Fri, 30 Oct 2015 at 00:51 Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> The really key argument that hasn't been addressed here is why does such >> a behavior belong in psql, rather than elsewhere? Surely legibility >> problems aren't unique to psql users. Moreover, there are exactly >> parallel facilities for other datatypes on the server side: think >> DateStyle or bytea_output. So if you were trying to follow precedent >> rather than invent a kluge, you'd have submitted a patch to create a GUC >> that changes the output of boolout(). >> > > I find Tom's analogy to datestyle and bytea_output convincing. > > +1 for a GUC that changes the behaviour of boolout. > > > -1 for changing boolout(). It will break anything that receives boolean > values from the server. How a client is going to display values (of any > type) is logic that should belong in the client, not in the protocol. > This is not fully valid, because transformation from binary to text is processed on server side. And client side transformation is easy only for scalar values. Regards Pavel
Commits
-
Add \pset options for boolean value display
- 645cb44c5490 19 (unreleased) landed