Re: psql: add \pset true/false

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Marko Tiikkaja <marko(at)joh(dot)to>, 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 12:50:40
Message-ID: CAB7nPqQMOOLpZCGsuxUo9wK0nSRybC=hVBCz77Tt2mwtx9oytg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Oct 29, 2015 at 10:50 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Marko Tiikkaja <marko(at)joh(dot)to> writes:
>> On 10/29/15 11:51 AM, Daniel Verite wrote:
>>> Personally I think it would be worth having, but how about
>>> booleans inside ROW() or composite types ?
>
>> There's not enough information sent over to do that in the client.
>> Note that this works the same way as \pset null with SELECT
>> ROW(NULL), so I don't consider it a show stopper for the patch.
>
> The problem with that argument is that \pset null is already a kluge
> (but at least a datatype-independent one). Now you've added a datatype
> specific kluge of the same ilk. It might be useful, it might be short,
> but that doesn't make it not a kluge.

FWIW, I am -1 on the concept of enforcing output values for particular
datatypes because that's not the job of psql, and it is easy to do
that at query level (no comment about the existing \pset NULL stuff).

+ fprintf(output, _(" true set the string to be
prined in place of a TRUE value\n"));
+ fprintf(output, _(" false set the string to be
prined in place of a FALSE value\n"));
s/prined/printed/
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kouhei Kaigai 2015-11-12 12:59:47 Re: CustomScan support on readfuncs.c
Previous Message Kouhei Kaigai 2015-11-12 12:45:48 Re: [DESIGN] ParallelAppend