From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-patches(at)postgresql(dot)org, Petr Jelinek <pjmodos(at)parba(dot)cz>, Stephen Frost <sfrost(at)snowman(dot)net> |
Subject: | Re: per user/database connections limit again |
Date: | 2005-08-03 14:03:06 |
Message-ID: | 941.1123077786@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Am Montag, 1. August 2005 16:08 schrieb Bruce Momjian:
>>> Would this not work in the context of the general user-specific ALTER
>>> USER ... SET something = something?
>>
>> No because it isn't a GUC variable, it is per-user/db value.
> GUC supports per-user/per-db values.
But not in the style that we'd want this to work. You couldn't just
invent a single "connection_limit" variable, because a per-user setting
would override a per-database setting, which is not the desired
behavior. You'd have to invent two separate GUC variables, and there
would be nothing except convention enforcing that they be set through
ALTER USER and ALTER DATABASE rather than at other random places.
We could do it that way, but it strikes me as messy and confusing,
and I don't see any actual benefit other than saving a few lines of
(already written) code. In what way would a GUC-based implementation
be more useful than what's there?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Fuhr | 2005-08-03 14:31:25 | ECPG and escape strings |
Previous Message | Peter Eisentraut | 2005-08-03 12:54:27 | Re: per user/database connections limit again |