Re: proposal, patch: allow multiple plpgsql plugins

Hello

updated patch - now plugin_info is per plpgsq_estate/plugin again.

Regards

Pavel

2014-01-17 20:26 GMT+01:00 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:

>
>
>
> 2014/1/16 Marko Tiikkaja <marko(at)joh(dot)to>
>
>> Hi Pavel,
>>
>> First of all, thanks for working on this!
>>
>>
>> On 1/12/14, 8:58 PM, Pavel Stehule wrote:
>>
>>> I still not happy with plugin_info - it is only per plugin now and should
>>> be per plugin and per function.
>>>
>>
>> I'm not sure I understand the point of plugin_info in the first place,
>> but what would having a separate info per (plugin, function) achieve that
>> can't be done otherwise?
>>
>
> First use case - I would to protect repeated call of
> plpgsql_check_function in passive mode. Where I have to store information
> about successful first start? It is related to the function instance, so
> function oid can be ambiguous (for function with polymorphic parameters).
> When function instance is destroyed, then this information should be
> destroyed. It is impossible do this check from plugin. Second use case -
> attach session life cycle plugin data with some function - for example for
> coverage calculation. Inside plugin without function specific data you have
> to hold a hash of all used function, and you have to search again and
> again. When plpgsql hold this info in internal plpgsql function structures,
> then you don't need search anything.
>
>
>
>
> Regards
>
> Pavel
>
>
>
>>
>>
>> As for the current patch, I'd like to see improvements on a few things:
>>
>> 1) It doesn't currently compile because of extra semicolons in the
>> PLpgSQL_plugin struct.
>>
>> 2) The previous comment above the same struct still talk about the
>> rendezvous variable which is now gone. The comment should be
>> updated to reflect the new API.
>>
>> 3) The same comment talks about how important it is to unregister a
>> plugin if its _PG_fini() is ever called, but the current API does
>> not support unregistering. That should probably be added? I'm not
>> sure when _PG_fini() would be called.
>>
>> 4) The comment /* reserved for use by optional plugin */ seems a bit
>> weird in its new context.
>>
>>
>> Regards,
>> Marko Tiikkaja
>>
>
>