On Monday, October 23, 2023, Laurenz Albe <laurenz.a...@cybertec.at> wrote:
> On Mon, 2023-10-23 at 08:35 -0700, David G. Johnston wrote: > > > along with not translating (none) and (default) and thus making the data > contents > > of these views environment independent. But minimizing the variance of > these command's > > output across systems doesn't seem like a design goal that is likely to > gain consensus > > and is excessive when viewed within the framework of these being only > for human consumption. > > 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. 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. 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. David J.
