From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Daniel Verite <daniel(at)manitou-mail(dot)org> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Add \pset options for boolean value display |
Date: | 2025-06-25 18:21:56 |
Message-ID: | CAKFQuwZQUCiCc3c1JESS=q33maA2y_A4K-ZyZ1u_v8EnEG869Q@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jun 25, 2025 at 11:03 AM Daniel Verite <daniel(at)manitou-mail(dot)org>
wrote:
> David G. Johnston wrote:
>
> > > It's \pset null for boolean values
> > >
> >
> > v1, Ready aside from bike-shedding the name.
>
> An annoying weakness of this approach is that it cannot detect
> booleans inside arrays or composite types
Arrays are probably doable. The low volume of composite literal outputs is
not worth worrying about.
> or COPY output,
> meaning that the translation of t/f is incomplete.
>
pset doesn't affect COPY output ever so this doesn't seem problematic.
> Also it reminds of a previous discussion (see [1]) where pretty much
> the same idea was proposed (and eventually rejected at the time).
>
>
> [1] https://postgr.es/m/56308F56.8060908%40joh.to
>
>
Ok, so yes, I really want this hack in psql. It fits with pset formats and
affects our \d and other table-producing meta-commands. Plus I'd like to
use it for documentation examples.
Maybe that's enough to change some decade-old opinions. Mine's apparently
changed since then.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2025-06-25 18:23:41 | Re: Huge commitfest app update upcoming: Tags, Draft CF, Help page, and automated commitfest creat/open/close |
Previous Message | Alexander Pyhalov | 2025-06-25 18:07:22 | Re: SCRAM pass-through authentication for postgres_fdw |