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 (tgl@sss.pgh.pa.us) wrote:
> > Alvaro Herrera <alvherre@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