Thread: Add \pset options for boolean value display
Hi!
Please accept this patch (though it's not finished, just functional)!
It's \pset null for boolean values
Printing tables of 't' and 'f' makes for painful-to-read output. This provides an easy win for psql users, giving them the option to do better. I would like all of our documentation examples eventually to be done with "\pset display_true true" and "\pset display_false false" configured. Getting it into v18 so docs being written now, like my NULL patch, can make use of it, would make my year.
I was initially going to go with the following to mirror null even more closely.
\pset { true | false } value
And still like that option, though having the same word repeated as the expected value and name hurts it a bit.
This next one was also considered but the word "print" already seemed a bit too entwined with \pset format related stuff.
\pset { print_true | print_false } value
David J.
Attachment
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Thu, Mar 20, 2025 at 8:24 PM David G. Johnston <
> david.g.johnston@gmail.com> wrote:
>> It's \pset null for boolean values
> v1, Ready aside from bike-shedding the name.
Do we really want this? It's the sort of thing that has a strong
potential to break anything that reads psql output --- and I'd
urge you to think that human consumers of psql output may well
be the minority. There's an awful lot of scripts out there.
I concede that \pset null hasn't had a huge amount of pushback,
but that doesn't mean that making boolean output unpredictable
will be cost-free. And the costs won't be paid by you (or me),
but by people who didn't ask for it.
regards, tom lane
David G. Johnston wrote: > > It's \pset null for boolean values > > > > v1, Ready aside from bike-shedding the name. An annoying weakness of this approach is that it cannot detect booleans inside arrays or composite types or COPY output, meaning that the translation of t/f is incomplete. Also it reminds of a previous discussion (see [1]) where pretty much the same idea was proposed (and eventually rejected at the time). [1] https://postgr.es/m/56308F56.8060908%40joh.to Best regards, -- Daniel Vérité https://postgresql.verite.pro/
On Wed, Jun 25, 2025 at 11:03 AM Daniel Verite <daniel@manitou-mail.org> wrote:
David G. Johnston wrote:
> > It's \pset null for boolean values
> >
>
> v1, Ready aside from bike-shedding the name.
An annoying weakness of this approach is that it cannot detect
booleans inside arrays or composite types
Arrays are probably doable. The low volume of composite literal outputs is not worth worrying about.
or COPY output,
meaning that the translation of t/f is incomplete.
pset doesn't affect COPY output ever so this doesn't seem problematic.
Also it reminds of a previous discussion (see [1]) where pretty much
the same idea was proposed (and eventually rejected at the time).
[1] https://postgr.es/m/56308F56.8060908%40joh.to
Ok, so yes, I really want this hack in psql. It fits with pset formats and affects our \d and other table-producing meta-commands. Plus I'd like to use it for documentation examples.
Maybe that's enough to change some decade-old opinions. Mine's apparently changed since then.
David J.