7 ms·
This is a fairly sane place to be in terms of bang for your buck. It's easy to find yourself in a place where authorization data and logic span multiple service
by jzelinskie 2y ago
This is a fairly sane place to be in terms of bang for your buck. It's easy to find yourself in a place where authorization data and logic span multiple services and at that point having everything deeply siloed into Postgres might be a doozy. That being said, there are plenty of times that'll never be the case and you should try to lean on the abstractions that work best for you.
- ludston 2y agoRoles are for services not for users. If you have a read-only Web api then it makes sense to use a read-only role regardless of which user is using it.
- _jhqp 2y agoEverything in PostgreSQL is a role. It's just named such that when a ROLE allows `login` it's considered a user
- skissane 2y agoThis is part of what many people find so confusing. In most systems “role” is a group (or something closely resembling a group), not a user. The weird terminology confuses beginners
- _jhqp 2y agoIt's a bit confusing and legacy. All roles function like you would expect groups to function A role that is not allowed to login is a `group`. While the CREATE USER and CREATE GROUP commands still exist, they are simply aliases for CREATE ROLE.
- orthoxerox 2y agoSomeone was feeling very clever when they came up with this idea.
- paulddraper 2y agoIt makes a lot of sense, especially since in the SQL standard, you can grant privileges to "users" or "roles." Might as well simplify the mental model and make them the same.
- cqqxo4zV46cp 2y agoTo me, the comment you are replying to is saying that you should^ DIFFERENTIATE roles by service, not ‘end user’.