Re: [BUGS] Patch to allow C extension modules to initialize/finish - Mailing list pgsql-hackers

From Joe Conway
Subject Re: [BUGS] Patch to allow C extension modules to initialize/finish
Date
Msg-id 44D28027.3090608@joeconway.com
Whole thread Raw
In response to Re: [BUGS] Patch to allow C extension modules to initialize/finish  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Zoltan Boszormenyi
Date:
Subject: Re: GENERATED ... AS IDENTITY, Was: Re: Feature Freeze
Next
From: elein
Date:
Subject: Re: User-defined typle similar to char(length) varchar(length)