> On Oct 21, 2025, at 04:51, David G. Johnston <david.g.johnston@gmail.com> wrote:
>
> On Monday, October 20, 2025, Álvaro Herrera <alvherre@kurilemu.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
limitationor 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,
ifa 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
fineto skip the check for it.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
