Re: proposal, patch: allow multiple plpgsql plugins - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: proposal, patch: allow multiple plpgsql plugins
Date
Msg-id CAFj8pRDddjYXEzvOUtaLBkRPp155Jaa1pXQzUj+7=oAcaQ0JPw@mail.gmail.com
Whole thread Raw
In response to Re: proposal, patch: allow multiple plpgsql plugins  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
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.stehule@gmail.com>:



2014/1/16 Marko Tiikkaja <marko@joh.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


Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: trgm regex index peculiarity
Next
From: Tomas Vondra
Date:
Subject: Re: GIN improvements part2: fast scan