Re: Add \pset options for boolean value display

> On Oct 21, 2025, at 04:51, David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>
> On Monday, October 20, 2025, Álvaro Herrera <alvherre(at)kurilemu(dot)de> wrote:
> On 2025-Jun-24, David G. Johnston wrote:
>
> > v1, Ready aside from bike-shedding the name.
>
> Here's v2 after some kibitzing. What do you think?
>
> Thank you. Seems good from a quick read. I’m regretting the choice of the display_ prefix; is there any technical limitation or other opposition to using just true and false?
>
> \pset true ‘true’
> \pset false ‘false’
>
> To keep in line with:
>
> \pset null ‘(null)’
>

+1. Especially, when I see the newly added test case:

```
+prepare q as select null as n, true as t, false as f;
+\pset null '(null)'
+\pset display_true 'true'
+\pset display_false 'false'
```

Looks inconsistant. If we decided to use “display_xx” then we should have renamed “null” to “display_null”.

The other thing I am thinking is that, with this patch, users are allowed to display arbitrary strings for true/false, if a user mistakenly set display_true to f and display_false to t, which will load to misunderstanding.

```
evantest=# \pset display_true f
Boolean true display is "f".
evantest=# \pset display_false t
Boolean false display is "t".
evantest=# select true as t, false as f;
t | f
---+---
f | t
(1 row)
```

Can we perform a basic sanity check to prevent this kind of error-prone behavior? The consideration applies to the “null” option, but since “null” lacks a clear opposite string representation (unlike “true”/“t" and “false”/“f”), it’s fine to skip the check for it.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/