Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > As much as I would like the URERLIMIT hacks removed for 8.0 I am thinking
> > we are too far along in release and don't have enough time to figure out
> > how to do the security definer function cleanly.
>
> What does that have to do
Bruce Momjian <[EMAIL PROTECTED]> writes:
> As much as I would like the URERLIMIT hacks removed for 8.0 I am thinking
> we are too far along in release and don't have enough time to figure out
> how to do the security definer function cleanly.
What does that have to do with it? We aren't the ones
Andrew McMillan wrote:
-- Start of PGP signed section.
> On Tue, 2004-11-09 at 13:58 -0500, Tom Lane wrote:
> >
> > Bruce and I were chatting about this on the phone today, and we were
> > seriously considering a more radical proposal: get rid of the whole
> > concept of USERLIMIT variables, and m
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Why not? You can put whatever restrictions you like in such a function.
> I assume to do this in a function you would have to create a temp table
> to store the original setting?
Not at all. You could use "RESET foo" to see what the
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Sure. There is a workaround for that though, which is to provide a
> >> SECURITY DEFINER function for the app to call that will adjust the
> >> logging level for it, rather than trying to do the SET directly in
>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Sure. There is a workaround for that though, which is to provide a
>> SECURITY DEFINER function for the app to call that will adjust the
>> logging level for it, rather than trying to do the SET directly in
>> unprivileged code.
> But
Tom Lane wrote:
> Andrew McMillan <[EMAIL PROTECTED]> writes:
> > The current functionality could be useful inside particular code paths
> > of an application, where you want to increase the log verbosity in a
> > particular part of the code, when it (unpredictably) happens, without
> > nuking the
Andrew McMillan <[EMAIL PROTECTED]> writes:
> The current functionality could be useful inside particular code paths
> of an application, where you want to increase the log verbosity in a
> particular part of the code, when it (unpredictably) happens, without
> nuking the logs entirely.
> Of course
On Tue, 2004-11-09 at 13:58 -0500, Tom Lane wrote:
>
> Bruce and I were chatting about this on the phone today, and we were
> seriously considering a more radical proposal: get rid of the whole
> concept of USERLIMIT variables, and make the logging variables be plain
> SUSET (ie, only superusers c
Without USERLIMIT, we could easily change the rules to make ALTER USER
work the way you want: we'd say you have to be superuser to issue ALTER
USER or ALTER DATABASE with a SUSET variable (already true), and then
the value can be adopted at session start in all cases since we can
then
treat pg_sha
Sean Chittenden <[EMAIL PROTECTED]> writes:
>> It strikes me that a more useful definition would be to say that you
>> must be superuser, period, to install an ALTER USER/DATABASE value for
>> any USERLIMIT variable; and then we could treat these values as
>> privileged for USERLIMIT purposes. Thi
doh! So much for that idea. There's no real way to have some
useconfig variables run by the super user and some run by the session
user. My workaround is to have the program call a SECURITY DEFINER
function, but I'd be nice to be able to remove that hack.
Yeah, the whole concept of USERLIMIT GUC
Sean Chittenden <[EMAIL PROTECTED]> writes:
> doh! So much for that idea. There's no real way to have some
> useconfig variables run by the super user and some run by the session
> user. My workaround is to have the program call a SECURITY DEFINER
> function, but I'd be nice to be able to rem
I've got a particular database account that connects/disconnects
hundreds of times a second, literally (email delivery agent). Being
the ever ready logger that I am, I have a number of logging bits turned
on to help me identify problems when they come up. In this case, I'm
not worried about a
14 matches
Mail list logo
