Peter Eisentraut <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
