|From:||Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>|
|Cc:||tgl(at)sss(dot)pgh(dot)pa(dot)us, masao(dot)fujii(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org|
|Subject:||Re: alter user set local_preload_libraries.|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> > I found this issue when trying per-pg_user (role) loading of
> > auto_analyze and some tweaking tool. It is not necessarily set by
> > the user by own, but the function to decide whether to load some
> > module by the session-user would be usable, at least, as for me:)
> I think we could just set local_preload_libraries to PGC_USERSET and
> document that subsequent changes won't take effect. That's the same way
> session_preload_libraries works. That would avoid inventing another
> very specialized GUC context.
It is enough for me. Since the only advantage of
PGC_BACKEND_USERSET is the capability to inhibit in-session
modification and I don't see another use case for it, I have no
objection for your opinion.
> If you're interested in improving this area, I also suggest you read the
> thread of
Although I don't understand even after reading this why
local_preload_libraries was PGC_SUSET, there seems to be no
reason it should be so.
The attached patch simply changes the context for local_... to
PGC_USERSET and edits the doc.
NTT Open Source Software Center
|Next Message||Michael Paquier||2014-09-01 11:58:29||Re: pg_receivexlog and replication slots|
|Previous Message||Andres Freund||2014-09-01 11:50:50||Re: Decoding of (nearly) empty transactions and regression tests|