Re: Limiting per user and per db accesse (was TODO list)

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

In response to

Responses

Browse pgsql-hackers by date

  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