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
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 |