On Fri, Jun 9, 2017 at 11:22 AM, Joe Conway <m...@joeconway.com> wrote:
> On 06/09/2017 08:56 AM, Ken Tanzer wrote: > > The extra logging would be undesirable. Is there any way to skip that > > entirely? I see with block_log_statement I could dial down the logging > > after switching users, but that would require the app to be aware of > > what the current "normal" logging level was. > > Also from the README: > --- > Notes: > > If set_user.block_log_statement is set to "off", the log_statement > setting is left unchanged. > --- > > So assuming you do not normally have statements being logged, this would > not change that. > > Despite reading that, I was a little uncertain because of it being called block_log_statement. It seems like conceptually it's really log_all_statements, though I suspect you won't want to change the name in midstream. FWIW, it would be clearer at least to me if you took the two statements in the description: - log_statement setting is set to "all", meaning every SQL statement executed while in this state will also get logged. - If set_user.block_log_statement is set to "on", SET log_statement and variations will be blocked. And this one from the notes: And this one from the notes: - If set_user.block_log_statement is set to "off", the log_statement setting is left unchanged. And combined them together: If set-user.block_log_statement is set to "on", log_statement setting is set to "all", meaning every SQL statement executed while in this state will also get logged. SET log_statement and variations will be blocked. If set to "off," the log statement setting is left unchanged. > > Any other pitfalls I'm not seeing, or reasons this might be a bad idea? > > As noted in the README, set_user will refuse to run inside a transaction > block, but other than that none that I know of. Of course if you come up > with any I'd be very interested to hear about them. > > If I go this route, get it up and running and find any, I'll be happy to let you know. :) Thanks a lot for your help! Ken > Joe > > -- > Crunchy Data - http://crunchydata.com > PostgreSQL Support for Secure Enterprises > Consulting, Training, & Open Source Development > > -- AGENCY Software A Free Software data system By and for non-profits *http://agency-software.org/ <http://agency-software.org/>* *https://agency-software.org/demo/client <https://agency-software.org/demo/client>* ken.tan...@agency-software.org (253) 245-3801 Subscribe to the mailing list <agency-general-requ...@lists.sourceforge.net?body=subscribe> to learn more about AGENCY or follow the discussion.
