Re: Add \pset options for boolean value display

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