Re: Users, Roles and Connection Pooling

2019-10-02 Thread raf
Rob Sargent wrote: > On 10/2/19 5:27 PM, raf wrote: > > > > > I can't help with questions about scale but I like to give roles/users > > almost no permissions at all. i.e. They can't select, insert, update > > or delete anything. All they have permission to do is to execute stored > > functions t

Re: Users, Roles and Connection Pooling

2019-10-02 Thread Rob Sargent
On 10/2/19 5:27 PM, raf wrote: I can't help with questions about scale but I like to give roles/users almost no permissions at all. i.e. They can't select, insert, update or delete anything. All they have permission to do is to execute stored functions that were installed by a role with the n

Re: Users, Roles and Connection Pooling

2019-10-02 Thread raf
> On Wed, 2019-10-02 at 08:46 +1000, Matt Andrews wrote: > > Here’s a question I’ve been asking for a while and just can’t find an > > answer to, so I thought I’d ask it here. The answer could be > > subjective, but here goes... > > > > When a web app connects to Postgres via a connection pooler,

Re: Users, Roles and Connection Pooling

2019-10-02 Thread Stephen Frost
Greetings, (we don't top-post on these lists, fyi, please reply in-line and trim) * Matt Andrews (mattandr...@massey.com.au) wrote: > I have little experience in this area, but it seems like having a Postgres > role for every application user is the right way to do things. It’s just > that it als

Re: Users, Roles and Connection Pooling

2019-10-02 Thread Matt Andrews
Yes, I’ll be more clear with the terminology. When I say user, I mean an individual application user, which most likely is a person. I’m also asking about this in a general sense, being concerned more with implementation details. The Postgres role system is really powerful and versatile, why shou

Re: Users, Roles and Connection Pooling

2019-10-02 Thread Rob Sargent
> On Oct 2, 2019, at 3:41 AM, Matt Andrews wrote: > > I have little experience in this area, but it seems like having a Postgres > role for every application user is the right way to do things. It’s just that > it also seems really inconvenient. > > For example how to map an application’s us

Re: Users, Roles and Connection Pooling

2019-10-02 Thread Matt Andrews
I have little experience in this area, but it seems like having a Postgres role for every application user is the right way to do things. It’s just that it also seems really inconvenient. For example how to map an application’s users/people table to Postgres roles? The pg_role name field is limite

Re: Users, Roles and Connection Pooling

2019-10-02 Thread Stephen Frost
Greetings, * Laurenz Albe (laurenz.a...@cybertec.at) wrote: > A couple of pointers: I generally agree with these comments. > - This is a good setup if you don't have too many users. Metadata > queries will start getting slow if you get into the tens of thousands > of users, maybe earlier.

Re: Users, Roles and Connection Pooling

2019-10-02 Thread Laurenz Albe
On Wed, 2019-10-02 at 08:46 +1000, Matt Andrews wrote: > Here’s a question I’ve been asking for a while and just can’t find an > answer to, so I thought I’d ask it here. The answer could be > subjective, but here goes... > > When a web app connects to Postgres via a connection pooler, what is > th

Users, Roles and Connection Pooling

2019-10-01 Thread Matt Andrews
Hey all, Here’s a question I’ve been asking for a while and just can’t find an answer to, so I thought I’d ask it here. The answer could be subjective, but here goes... When a web app connects to Postgres via a connection pooler, what is the best way to manage privileges for the connecting user?