Hi Pavel,
The extra semicolons are still in there; around line 525 in this patch.
However, I removed them to compile the patch, but I can't compile my
plugin on OS X. The plugin is simple, it just does:
void
_PG_init(void)
{
DirectFunctionCall1(plpgsql_register_plugin,
Hi
2014-03-02 19:59 GMT+01:00 Marko Tiikkaja ma...@joh.to:
Hi Pavel,
The extra semicolons are still in there; around line 525 in this patch.
However, I removed them to compile the patch, but I can't compile my
plugin on OS X. The plugin is simple, it just does:
void
_PG_init(void)
{
On 3/2/14, 8:47 PM, Pavel Stehule wrote:
2014-03-02 19:59 GMT+01:00 Marko Tiikkaja ma...@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?
Dne 2. 3. 2014 21:55 Marko Tiikkaja ma...@joh.to napsal(a):
On 3/2/14, 8:47 PM, Pavel Stehule wrote:
2014-03-02 19:59 GMT+01:00 Marko Tiikkaja ma...@joh.to:
Undefined symbols for architecture x86_64:
_plpgsql_register_plugin, referenced from:
__PG_init in plpgtest.o
I'm
2014-03-03 6:09 GMT+01:00 Pavel Stehule pavel.steh...@gmail.com:
Dne 2. 3. 2014 21:55 Marko Tiikkaja ma...@joh.to napsal(a):
On 3/2/14, 8:47 PM, Pavel Stehule wrote:
2014-03-02 19:59 GMT+01:00 Marko Tiikkaja ma...@joh.to:
Undefined symbols for architecture x86_64:
Hello Marko
2014-01-16 23:54 GMT+01:00 Marko Tiikkaja ma...@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
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.steh...@gmail.com:
2014/1/16 Marko Tiikkaja ma...@joh.to
Hi Pavel,
First of all, thanks for working on this!
On 1/12/14, 8:58 PM, Pavel Stehule
2014/1/16 Marko Tiikkaja ma...@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
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
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
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
2014/1/12 Marko Tiikkaja ma...@joh.to
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
Hello
Updated version
I still not happy with plugin_info - it is only per plugin now and should
be per plugin and per function.
Regards
Pavel
2014/1/12 Pavel Stehule pavel.steh...@gmail.com
2014/1/12 Marko Tiikkaja ma...@joh.to
On 1/12/14, 5:33 PM, I wrote:
On 1/9/14, 11:41 PM,
Hello
We talked about enhancing a plpgsql plugin API to support more active
plugins.
I wrote a prototype based on function plpgsql_register_plugin instead
rendezvous variable.
There are two basic questions:
a) will we support rendezvous variable still?
b) will we support same API still - a
14 matches
Mail list logo
