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 по дате отправления: