Re: Fix output of zero privileges in psql

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Fix output of zero privileges in psql
Дата
Msg-id 377395.1698073029@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Fix output of zero privileges in psql  ("David G. Johnston" <david.g.johnston@gmail.com>)
Ответы Re: Fix output of zero privileges in psql
Список pgsql-hackers
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> We document default privileges print as an empty string - I do not think we
> should change the definition to "default privileges print null which can be
> controlled via \pset null", and regardless of preference doing so is not a
> bug.

Well, "if it's documented it's not a bug" is a defensible argument
for calling something not a bug, but it doesn't address the question
of whether changing it would be an improvement.  I think it would be,
and I object to your claim that we have a consensus to not do that.

The core of the problem here, IMO, is exactly that there is confusion
between whether a visibly empty string represents NULL (default
privileges) or an empty ACL (no privileges).  I believe we have agreed
that printing "(none)" or some other clearly-not-an-ACL-entry string
for the second case is an improvement, even though that's a change
in behavior.  That doesn't mean that changing the other case can't
also be an improvement.  I think it'd be less confusing all around
if this instance of NULL prints like other instances of NULL.

IOW, the current definition is "NULL privileges print as an empty
string no matter what", and I don't think that serves to reduce
confusion about whether an ACL is NULL or not.  We ought to be doing
what we can to make clear that such an ACL *is* NULL, because
otherwise people won't understand how it differs from an empty ACL.

            regards, tom lane



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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: Casual Meson fixups
Следующее
От: Mark Wong
Дата:
Сообщение: Re: LLVM 16 (opaque pointers)