From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Álvaro Herrera <alvherre(at)kurilemu(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Add \pset options for boolean value display |
Date: | 2025-10-21 03:37:12 |
Message-ID: | 417647.1761017832@sss.pgh.pa.us |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Monday, October 20, 2025, David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Guo | 2025-10-21 03:58:53 | Re: Inconsistent Behavior of GROUP BY ROLLUP in v17 vs master |
Previous Message | John Naylor | 2025-10-21 03:30:30 | Re: Proposal for enabling auto-vectorization for checksum calculations |