Re: Fix output of zero privileges in psql

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: Fix output of zero privileges in psql
Дата
Msg-id CAKFQuwaqHy=ZD7V2sXmH3w9kpVT4f3EmsKmSwy27P2eufLhO1w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Fix output of zero privileges in psql  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Fix output of zero privileges in psql  (Erik Wienhold <ewie@ewie.name>)
Список pgsql-hackers
On Mon, Oct 9, 2023 at 12:13 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Laurenz Albe <laurenz.albe@cybertec.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.

My position is that the default behavior should be changed such that the distinction these reports need to make between empty privileges and default privileges is impossible for the user to remove.  I suppose the best direct solution given that goal is for the query to simply do away with any reliance on NULL being an indicator.  Output an i18n'd "no permissions present" line in the rare empty permissions situation and leave the empty string for built-in default.

If the consensus is to not actually fix these views to make them environment invariant in their accuracy then so be it.  Having them obey \pset null seems like a half-measure but it at least is an improvement over the status quo such that users are capable of altering their system to make the reports distinguish the two cases if they realize the need.

I do agree that my suggestion regarding the implicit \pset null, while plausible, leaves the wart that NULL is being used to mean something specific.  Better is to just use a label for that specific thing.

David J.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jelte Fennema
Дата:
Сообщение: Re: Request for comment on setting binary format output per session
Следующее
От: Andres Freund
Дата:
Сообщение: Re: New WAL record to detect the checkpoint redo location