I'd welcome input from other people on this issue; only now I noticed that it's buried in pgsql-docs, so CCing pgsql-hackers now.
On 2020-Apr-23, Stephen Frost wrote: > Greetings, > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > Alvaro Herrera <alvhe...@2ndquadrant.com> writes: > > > I had it in my mind that LOGIN was for regular (SQL-based) login, and > > > REPLICATION was for replication login, and that they were orthogonal. > > > > Yeah, that's what I would've expected. Otherwise, is REPLICATION > > without LOGIN useful at all? > > No, but it's less surprising, at least to me, for all roles that login > to require having the LOGIN right. Having REPLICATION ignore that would > be surprising (and a change from today). Maybe if we called it > REPLICATIONLOGIN or something along those lines it would be less > surprising, but it still seems pretty awkward. > > I view REPLICATION as allowing a specific kind of connection, but you > first need to be able to login. > > Also- what about per-database connections? Does having REPLICATION mean > you get to override the CONNECT privileges on a database, if you're > connecting for the purposes of doing logical replication? > > I agree we could do better in these areas, but I'd argue that's mostly > around improving the documentation rather than baking in implications > that one privilege implies another. We certainly get people who > complain about getting a permission denied error when they have UPDATE > rights on a table (but not SELECT) and they include a WHERE clause in > their update statement, but that doesn't mean we should assume that > having UPDATE rights means you also get SELECT rights, just because > UPDATE is next to useless without SELECT. > > Thanks, > > Stephen -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services