"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Wed, 17 Dec 2003, Tom Lane wrote:
>> I think group-related restrictions would be an impossible rat's nest to
>> define, because there's no one-to-one correspondence between backend
>> processes and groups.
> 'k, I'm a bit confused here ... we already do the 'user->group' checks at
> the table level, through GRANT/REVOKE ... why couldn't we do similar at
> the database level? If you were to know that the database *had* per group
> restrictions, when you check # of connections, all you'd need to do is
> figure out if user is part of GroupA and, if so, increment that count ...
> no?
Well, no, because I don't understand what the interaction of different
group settings ought to be. If user A is a member of groups G and H,
while user B is a member of groups H and J, how are you going to decide
whether a collection of M logins from A and N logins from B violate some
per-group limits? In particular do you want to say that the requirement
is on min() or on max() --- that is, must the configuration meet every
group's limit separately, or can you log in if there's at least one
group that says you can? I can imagine uses for both approaches, so
I don't think that's an idle question.
There's also an implementation-efficiency issue, which is how you check
such constraints without groveling through each entry in the pg_group
table. I think this could put a pretty serious hurt on our backend
startup time, *even if you are not using the feature at all*.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
