Re: psql: add \pset true/false

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Marko Tiikkaja <marko(at)joh(dot)to>
Cc: Daniel Verite <daniel(at)manitou-mail(dot)org>, PostgreSQL hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: psql: add \pset true/false
Date: 2015-11-12 20:56:00
Message-ID: 5644FCE0.2030405@gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-11-12 21:01:08 Re: Inaccurate results from numeric ln(), log(), exp() and pow()
Previous Message David G. Johnston 2015-11-12 20:11:49 Re: psql: add \pset true/false