| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
| Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Erik Wienhold <ewie(at)ewie(dot)name>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Fix output of zero privileges in psql |
| Date: | 2023-10-09 19:13:14 |
| Message-ID: | 180911.1696878794@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> writes:
> On Mon, 2023-10-09 at 09:30 -0700, David G. Johnston wrote:
>> My point with the second paragraph is that we could, instead of documenting the
>> caveat about null printing as empty strings is to instead issue an implicit
>> "\pset null '<null>'" as part of these commands, and a "\pset null" afterward,
>> conditioned upon it not already being set to a non-empty value. IOW, the
>> special-casing we do today but actually do it in a way that distinguishes the
>> two cases instead of forcing them to be indistinguishable.
> -1
> The whole point of this patch is to make psql behave consistently with respect to
> NULLs in meta-commands. Your suggestion would subvert that idea.
Yeah. There is a lot of attraction in having \pset null affect these
displays just like all other ones. The fact that they act differently
now is a wart, not something we should replace with a different special
case behavior.
Also, I'm fairly concerned about not changing the default behavior here.
The fact that this behavior has stood for a couple dozen years without
many complaints indicates that there's not all that big a problem to be
solved. I doubt that a new default behavior will be well received,
even if it's arguably better.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2023-10-09 19:34:27 | Re: should frontend tools use syncfs() ? |
| Previous Message | Dave Cramer | 2023-10-09 19:08:28 | Re: Request for comment on setting binary format output per session |