<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 1/2/24 1:38 PM, Robert Haas wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CA+Tgmoa6VFBze4Lecws9C1VBGn1VGZ5jozDEPU93Kb_dJ+h-sw(at)mail(dot)gmail(dot)com">
<pre>But to try to apply that concept
here means that we suppose the user knows whether the default is
INHERIT or NOINHERIT, whether the default is BYPASSRLS or NOBYPASSRLS,
etc. And I'm just a little bit skeptical of that assumption. Perhaps
it's just that I've spent less time doing user management than table
administration and so I'm the only one who finds this fuzzier than
some other kinds of SQL objects, but I'm not sure it's just that.
Roles are pretty weird.</pre>
</blockquote>
<p>In my consulting experience, it's extremely rare for users to do
anything remotely sophisticated with roles (I was always happy
just to see apps weren't connecting as a superuser...).</p>
<p>Like you, I view \du and friends as more of a "helping hand" to
seeing the state of things, without the expectation that every
tiny nuance will always be visible, because I don't think it's
practical to do that in psql. While that behavior might surprise
some users, the good news is once they start exploring non-default
options the behavior becomes self-evident.</p>
<p>Some attributes are arguably important enough to warrant their
own column. The most obvious is NOLOGIN, since those roles are
generally used for a very different purpose than LOGIN roles.
SUPERUSER might be another candidate (though, I much prefer a
dedicated "sudo role" than explicit SU on roles).</p>
<p>I'm on the fence when it comes to SQL syntax vs what we have now.
What we currenly have is more readable, but off-hand I think the
other places we list attributes we do it in SQL syntax. It might
be worth changing just for consistency sake.</p>
<p><font size="2">--<br>
Jim Nasby, Data Architect, Austin TX</font><br>
</p>
</body>
</html>