Subject: Re: psql: add \pset true/false
To: Tom Lane <tgl@sss.pgh.pa.us>, Marko Tiikkaja <marko@joh.to>
References: <0949c317-3ec4-4516-a3aa-33a6cfbf5267@mm>
 <5631FCAF.9060204@joh.to> <27336.1446126627@sss.pgh.pa.us>
Cc: Daniel Verite <daniel@manitou-mail.org>,
 PostgreSQL hackers <pgsql-hackers@postgresql.org>
From: Peter Eisentraut <peter_e@gmx.net>
Message-ID: <5644FCE0.2030405@gmx.net>
Date: Thu, 12 Nov 2015 15:56:00 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0)
 Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <27336.1446126627@sss.pgh.pa.us>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 10/29/15 9:50 AM, Tom Lane wrote:
> The really key argument that hasn't been addressed here is why does such
> a behavior belong in psql, rather than elsewhere?

Because it is the job of the client to mangle the data so that it suits
the purposes of the client.  What comes over the wire is part of the
protocol, not part of the client display.  Language drivers do this sort
of mangling all the time.

> Surely legibility problems aren't unique to psql users.

But the way to deal with it is specific to psql.  In a graphical
environment you might want a checkbox instead, say.  Different clients
will have different requirements and preferences.

> Moreover, there are exactly
> parallel facilities for other datatypes on the server side: think
> DateStyle or bytea_output.

Surely DateStyle is legacy, and bytea_output was actually a performance
feature.  And clients will still mangle either type into their own formats.

Plus we already have \pset numericlocale as a similar feature in psql.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers