Re: [BUGS] Patch to allow C extension modules to initialize/finish
От | Joe Conway |
---|---|
Тема | Re: [BUGS] Patch to allow C extension modules to initialize/finish |
Дата | |
Msg-id | 44D28027.3090608@joeconway.com обсуждение исходный текст |
Ответ на | Re: [BUGS] Patch to allow C extension modules to initialize/finish (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane wrote: > Joe Conway <mail@joeconway.com> writes: >>Tom Lane wrote: >> >>>Also, if we do this we probably ought to remove the special-purpose >>>hack for preload_libraries to specify an init function --- it should >>>just happen by default. Any objections to simplifying that? > >>The original idea of using the init function with preload_libraries was >>to eliminate library startup that was expensive and only needed once. >>Specifically in the case of libR (and presumably other libraries as >>well), the init time was much greater than the actual library load time. >>If it is removed from preload_libraries, then we'll pay that price for >>every backend startup, no? > > No, my thought is that you'd rename PL/R's init function to PG_init, and > then it'd get called automagically without needing to assume that the DBA > remembers to specify it in preload_libraries. If there's a reason *not* > to do that then it'd be a strike against this whole proposal, methinks. Oh, well that sounds perfect to me. At least in the case of a procedural language handler you can easily initialize and cache anything that must be done per-backend anyway. It's the "expensive but must be done at least once stuff" that was a problem. As long as that happens, I'm happy. And if we eliminate a dba dependency, so much the better. Joe
В списке pgsql-hackers по дате отправления: