On Mon, 2023-10-23 at 11:37 -0700, David G. Johnston wrote: > > I didn't understand this completely. You want default privileges displayed > > as > > "(default)", but are you for or against "\pset null" to have its normal > > effect on > > the output of backslash commands in all other cases? > > I haven’t inspected other cases but to my knowledge we don’t typically > represent > non-unknown things using NULL so I’m not expecting other places to have this > representation problem.
The first example that comes to my mind is the "ICU Locale" and the "ICU Rules" in the output of \l. There are many others. > I don’t think any of our meta-command outputs should modify pset null. > Left join cases should be considered unknown, represented as NULL, and obey > the > user’s setting. That's what I think too. psql output should respect "\pset null". So it looks like we agree on that. > I do believe that we should be against exposing, like in this case, any > internal > implementation detail that encodes something (e.g., default privileges) as > NULL > in the catalogs, to the user of the psql meta-commands. > > I won’t argue that exposing such NULLS is wrong, just it would preferable IME > to avoid doing so. NULL means unknown or not applicable and default > privileges > are neither of those things. I get why our catalogs choose such an encoding > and > agree with it, and users that find the need to consult the catalogs will need > to > learn such details. But we should strive for them to be able to survive with > psql meta-commands. Sure, it would be best to hide this implementation detail from the user. The correct way to do that would be to fake an ACL entry like "laurenz=arwdDxt/laurenz" if there is a NULL in the catalog, but that would add a ton of special-case code to psql, which does not look appealing at all. So we cannot completely hide the implementation, but perhaps "(default)" would be less confusing than a NULL value. If everybody agrees, I can modify the patch to do that. Yours, Laurenz Albe
