On Mon, 2023-10-23 at 22:43 -0400, Tom Lane wrote: > Laurenz Albe <laurenz.a...@cybertec.at> writes: > > On Mon, 2023-10-23 at 11:37 -0700, David G. Johnston wrote: > > > 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. > > > 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. > > For better or worse, that *is* the backend's catalog representation, > and I don't think that psql would be doing our users a service by > trying to obscure the fact. They'd run into it anyway the moment > they look at the catalogs with anything but a \d-something command.
... for example with a client like pgAdmin, which is a frequent choice of many PostgreSQL beginners (they display empty privileges). Yes, it is "(default)" or NULL. The former is friendlier for beginners, the latter incurs less backward incompatibility. I could live with either solution, but I am still leaning towards NULL. I ran the regression tests with a patch that displays "(default)", and I counted 22 failures, excluding the one added by my patch. The tests can of course be fixed, but perhaps that serves as a measure of the backward incompatibility. Yours, Laurenz Albe
