Stephen Frost <sfrost@snowman.net> writes:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> ISTM those statements are contradictory. The two privileges could
>> only be called orthogonal if it's possible to make use of one without
>> having the other. As things stand, REPLICATION without LOGIN is an
>> entirely useless setting.
> Allowing a login to the system by a role that doesn't have the LOGIN
> privilege isn't sensible though.
The fundamental issue here is whether a replication connection is a
"login". I'd argue that it is not; "login" ought to mean a normal
SQL connection.
I realize that a replication connection can issue SQL commands (which,
as I recall, Robert has blasted as a crappy design --- and I agree).
But it's already the case that a replication connection has much greater
privileges than plain SQL, so I don't think that that aspect ought to
compel us to design the privilege bits as they are set up now. If
you think that LOGIN should be required to issue SQL commands, then
shouldn't doing SET ROLE to a non-LOGIN role disable your ability
to issue SQL?
> Perhaps a middle ground would be to set LOGIN on a role when REPLICATION
> is set on it, if it's not already set (maybe with a NOTICE or WARNING or
> such saying "also enabling LOGIN for role X", or maybe not if people
> really think it should be obvious).
It seems to me that there's value in having a role that can only
connect for replication purposes and not as a regular SQL user.
The existing definition doesn't support that, and the rather silly
kluge you're proposing doesn't fix it.
regards, tom lane
