> On Oct 21, 2025, at 04:51, David G. Johnston <[email protected]>
> wrote:
>
> On Monday, October 20, 2025, Álvaro Herrera <[email protected]> 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/
