Thread: proposal, patch: allow multiple plpgsql plugins

On 1/9/14, 11:41 PM, Pavel Stehule wrote:
> There are two basic questions:
>
> b) will we support same API still - a reference on plugin_info in exec
> state is a issue - described in patch.

Pardon my ignorance, but why does the plugin_info have to be in the 
executor state?  If we're going to change the API, can't we pass it 
directly to the callback function?  Am I missing something completely 
obvious? :-)


Regards,
Marko Tiikkaja

On 1/12/14, 5:33 PM, I wrote:
> On 1/9/14, 11:41 PM, Pavel Stehule wrote:
>> There are two basic questions:
>>
>> b) will we support same API still - a reference on plugin_info in exec
>> state is a issue - described in patch.
>
> Pardon my ignorance, but why does the plugin_info have to be in the
> executor state?  If we're going to change the API, can't we pass it
> directly to the callback function?

Oh, I think I'm being stupid -- we'd only have to do what *if* we don't 
want to change the API?  Then my vote is for breaking the API.


Regards,
Marko Tiikkaja

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?


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
commentshould 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
thecurrent API does     not support unregistering.  That should probably be added?  I'm not     sure when _PG_fini()
wouldbe called.
 
  4) The comment  /* reserved for use by optional plugin */  seems a bit     weird in its new context.


Regards,
Marko Tiikkaja

Hi Pavel,

The extra semicolons are still in there; around line 525 in this patch.  However, I removed them to compile the patch,
butI can't compile my 
 
plugin on OS X.  The plugin is simple, it just does:

void
_PG_init(void)
{    DirectFunctionCall1(plpgsql_register_plugin, 
&pgt_plpgsql_plugin_struct);
}

I get:

Undefined symbols for architecture x86_64:  "_plpgsql_register_plugin", referenced from:      __PG_init in plpgtest.o

I'm guessing this is because PL/PgSQL is a shared library and not in 
core?  Is there a way around this?


Regards,
Marko Tiikkaja

On 3/2/14, 8:47 PM, Pavel Stehule wrote:
> 2014-03-02 19:59 GMT+01:00 Marko Tiikkaja <marko@joh.to>:
>> Undefined symbols for architecture x86_64:
>>    "_plpgsql_register_plugin", referenced from:
>>        __PG_init in plpgtest.o
>>
>> I'm guessing this is because PL/PgSQL is a shared library and not in core?
>>   Is there a way around this?
>>
>
> yes, PLpgSQL is not referenced and, if I remember well, clang is too
> restrictive.
>
> probably
> http://stackoverflow.com/questions/17281901/ignoring-an-undefined-symbol-in-a-dynamic-library-from-xcode
>
> or you can add a reference on plpgsql to your Makefile

That seems unbelievably ugly, but worse, loading the library in 
shared_preload_libraries doesn't work:

14782  FATAL:  could not load library 
"/usr/local/pgsql/lib/plpgtest.so": 
dlopen(/usr/local/pgsql/lib/plpgtest.so, 10): Symbol not found: 
_plpgsql_register_plugin  Referenced from: /usr/local/pgsql/lib/plpgtest.so  Expected in: flat namespace in
/usr/local/pgsql/lib/plpgtest.so

I even tried putting plpgsql.so before it in the list, but no go.


Regards,
Marko Tiikkaja

<p dir="ltr"><br /> Dne 2. 3. 2014 21:55 "Marko Tiikkaja" <<a href="mailto:marko@joh.to">marko@joh.to</a>>
napsal(a):<br/> ><br /> > On 3/2/14, 8:47 PM, Pavel Stehule wrote:<br /> >><br /> >> 2014-03-02 19:59
GMT+01:00Marko Tiikkaja <<a href="mailto:marko@joh.to">marko@joh.to</a>>:<br /> >>><br /> >>>
Undefinedsymbols for architecture x86_64:<br /> >>><br /> >>>    "_plpgsql_register_plugin",
referencedfrom:<br /> >>>        __PG_init in plpgtest.o<br /> >>><br /> >>> I'm guessing
thisis because PL/PgSQL is a shared library and not in core?<br /> >>>   Is there a way around this?<br />
>>><br/> >><br /> >> yes, PLpgSQL is not referenced and, if I remember well, clang is too<br />
>>restrictive.<br /> >><br /> >> probably<br /> >> <a
href="http://stackoverflow.com/questions/17281901/ignoring-an-undefined-symbol-in-a-dynamic-library-from-xcode">http://stackoverflow.com/questions/17281901/ignoring-an-undefined-symbol-in-a-dynamic-library-from-xcode</a><br
/>>><br /> >> or you can add a reference on plpgsql to your Makefile<br /> ><br /> ><br /> > That
seemsunbelievably ugly, but worse, loading the library in shared_preload_libraries doesn't work:<br /> ><br /> >
14782 FATAL:  could not load library "/usr/local/pgsql/lib/plpgtest.so": dlopen(/usr/local/pgsql/lib/plpgtest.so, 10):
Symbolnot found: _plpgsql_register_plugin<br /> >           Referenced from: /usr/local/pgsql/lib/plpgtest.so<br />
>          Expected in: flat namespace<br /> >          in /usr/local/pgsql/lib/plpgtest.so<br /> ><br /> >
Ieven tried putting plpgsql.so before it in the list, but no go.<br /><br /><p dir="ltr">><br /> ><br /> >
Regards,<br/> > Marko Tiikkaja<br /> In this moment, pls, try to use Load plpgsql<p dir="ltr">Regards<p
dir="ltr">pavel