From: | "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jonathan Gardner <jgardner(at)jonathangardner(dot)net>, David Felstead <David(dot)Felstead(at)colesmyer(dot)com(dot)au>, 'Postgresql Hackers' <pgsql-hackers(at)postgresql(dot)org>, 'Andrew Dunstan' <andrew(at)dunslane(dot)net> |
Subject: | Re: Limiting per user and per db accesse (was TODO list) |
Date: | 2003-12-18 03:03:33 |
Message-ID: | 20031217225922.X3016@ganymede.hub.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 17 Dec 2003, Tom Lane wrote:
> Jonathan Gardner <jgardner(at)jonathangardner(dot)net> writes:
> > - -- Group www can only have 12 concurrent connections with the cluster.
> > ALTER GROUP www SET max_connections = 12;
>
> 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. Per-user and per-database make sense to me,
> because a backend does have a well-defined (session) user and a
> well-defined database.
'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?
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664
From | Date | Subject | |
---|---|---|---|
Next Message | shaikat | 2003-12-18 03:13:47 | Suggestions welcome for PhD topic in Distributed Database Systems (Planning to contribute to postgresql) |
Previous Message | Andrew Dunstan | 2003-12-18 02:39:51 | Re: TODO list |