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 →
-
Add \pset options for boolean value display
- 645cb44c5490 19 (unreleased) landed
"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