Re: Add \pset options for boolean value display

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: "David G. Johnston" <david.g.johnston@gmail.com>
Cc: Chao Li <li.evan.chao@gmail.com>, Álvaro Herrera <alvherre@kurilemu.de>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-10-21T03:37:12Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Add \pset options for boolean value display

"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Monday, October 20, 2025, David G. Johnston <david.g.johnston@gmail.com>
> wrote:
>> Sympathetic to the concern but opposed to taking on such responsibility.
>> They could probably modify their own query to do that if they really wanted
>> to fool someone and I’m having trouble accepting this happening by
>> accident.  Do we test for yes/no; oui/non (i.e., foreign language choices);
>> checkmark/X?

> Actually, preventing t/f makes sense to me.  Prevents a “hacker” from
> messing with the default outputs in a hard-to-identify manner.  Any other
> value would point to pset being used.

-1.  Yeah, you could reject "\pset true 'f'", but what about
not-obviously-different values such as 'f ', or f with a non-breaking
space, or f with a tab, or yadda yadda yadda?

I went on record as opposed to this entire idea back at the start of
this thread, precisely because I was worried that it could lead to
confusion.  And I remain of the opinion that it's not a great idea.
But if we're going to do it, let's not bother with any fig-leaf
proposals that pretend to partially guard against confusion.

			regards, tom lane