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
signature.asc
Description: PGP signature
