On 11/15/19 8:59 AM, Andrew Dunstan wrote:
> On 11/14/19 3:21 PM, Alvaro Herrera wrote:
>> On 2019-Nov-14, Andrew Dunstan wrote:
>>
>>> I guess this would work. There would have to be a deal of code to load
>>> the library and lookup the symbol. Do we really think it's worth it?
>>> Leveraging shared_preload_libraries makes this comparatively simple.
>> Using the generic interface has the drawback that the user can make more
>> mistakes. I think that's part of Bruce's issue with it (although I may
>> misinterpret.)
>>
>> I think if you add most of it as a new entry point in dfmgr.c (where you
>> can leverage internal_library_load) and returns a function pointer to
>> the user specified function, it's all that much additional code.
>>
>> (I don't think you can use load_external_function as is, because it
>> assumes fmgr V1 calling convention, which I'm not sure serves your case.
>> But then maybe it does. And if not, then those 10 lines should be very
>> similar to the code you'd need to add.)
I've just been looking at that. load_external_function() doesn't
actually do anything V1-ish with the value, it just looks up the symbol
using dlsym and returns it cast to a PGFunction. Is there any reason I
can't just use that and cast it again to the callback function type?
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services