On Fri, Dec 28, 2012 at 12:24 AM, Pavel Stehule wrote:
> 2012/12/28 Peter Eisentraut :
>> On Mon, 2012-12-17 at 16:34 -0500, Peter Eisentraut wrote:
>>> Yes, this would be a good solution for some applications, but the only
>>> way I can think of to manage the compatibility issue is to invent some
On Fri, Dec 28, 2012 at 7:09 AM, Hannu Krosing wrote:
> thus
>
> CREATE FUNCTION foo(a int,b int, c text)
>
> would create module
>
> plpy.modules.foo_int4_int4_text
I don't know much of anything about Python, but keep in mind that
types can be renamed. It seems like that could break things if t
On 12/28/12 7:09 AM, Hannu Krosing wrote:
> Maybe just export the function with the same name as is defined in
> CREATE FUNCTION ?
>
> And in case we do want to override it, call it
>
> CREATE FUNCTION foo(a int,b int, c text) AS $$
> # plpython: module modulename
> import x,y,z
>
> def foo(a,b,
On 12/28/2012 09:15 AM, Peter Eisentraut wrote:
On Mon, 2012-12-17 at 16:34 -0500, Peter Eisentraut wrote:
Yes, this would be a good solution for some applications, but the only
way I can think of to manage the compatibility issue is to invent some
function attribute system like
CREATE FUNCTION
> On 12/28/2012 09:15 AM, Peter Eisentraut wrote:
>> An alternative that has some amount of precedent in the Python world
>> would be to use comment pragmas, like this: ...
>> This way we could get this done fairly easily without any new
>> infrastructure outside the language handler.
+1 for not c
On 12/28/2012 03:15 AM, Peter Eisentraut wrote:
On Mon, 2012-12-17 at 16:34 -0500, Peter Eisentraut wrote:
Yes, this would be a good solution for some applications, but the only
way I can think of to manage the compatibility issue is to invent some
function attribute system like
CREATE FUNCTIO
On 12/28/2012 09:15 AM, Peter Eisentraut wrote:
On Mon, 2012-12-17 at 16:34 -0500, Peter Eisentraut wrote:
Yes, this would be a good solution for some applications, but the only
way I can think of to manage the compatibility issue is to invent some
function attribute system like
CREATE FUNCTION
2012/12/28 Peter Eisentraut :
> On Mon, 2012-12-17 at 16:34 -0500, Peter Eisentraut wrote:
>> Yes, this would be a good solution for some applications, but the only
>> way I can think of to manage the compatibility issue is to invent some
>> function attribute system like
>>
>> CREATE FUNCTION ...
On Mon, 2012-12-17 at 16:34 -0500, Peter Eisentraut wrote:
> Yes, this would be a good solution for some applications, but the only
> way I can think of to manage the compatibility issue is to invent some
> function attribute system like
>
> CREATE FUNCTION ... OPTIONS (call_convention 'xyz')
An
Hannu Krosing writes:
> On 12/17/2012 10:34 PM, Peter Eisentraut wrote:
>> Yes, this would be a good solution for some applications, but the only
>> way I can think of to manage the compatibility issue is to invent some
>> function attribute system like
>>
>> CREATE FUNCTION ... OPTIONS (call_con
On 12/17/2012 10:34 PM, Peter Eisentraut wrote:
On 12/16/12 1:20 PM, Hannu Krosing wrote:
I was going to suggest some special function name to be pulled out of code
passed to CREATE FUNCTION in line with
CREATE FUNCTION foo(a,b,c) AS $$
import x
from __future__ import nex_coo
2012/12/17 Peter Eisentraut :
> On 12/16/12 1:20 PM, Hannu Krosing wrote:
>> I was going to suggest some special function name to be pulled out of code
>> passed to CREATE FUNCTION in line with
>>
>> CREATE FUNCTION foo(a,b,c) AS $$
>> import x
>> from __future__ import nex_cool_fea
On 12/16/12 1:20 PM, Hannu Krosing wrote:
> I was going to suggest some special function name to be pulled out of code
> passed to CREATE FUNCTION in line with
>
> CREATE FUNCTION foo(a,b,c) AS $$
> import x
> from __future__ import nex_cool_feature
>
> def helper_function
On 12/16/2012 10:23 PM, Peter Eisentraut wrote:
On Sun, 2012-12-16 at 19:13 +0100, Hannu Krosing wrote:
As an idea seems quite good, but maybe the "run once" part could use
its
own keyword in the future, something like PREPARE or REQUIRE?
Well, either we do it in a language independent way, in
On Sun, 2012-12-16 at 13:03 -0500, Tom Lane wrote:
> Sure, but wouldn't it be cleaner to do that via some language-specific
> syntax inside the function string? I'm imagining some syntax like
>
> CREATE FUNCTION ... AS $$
> global[ some definitions here ]
> function code h
On Sun, 2012-12-16 at 19:13 +0100, Hannu Krosing wrote:
> As an idea seems quite good, but maybe the "run once" part could use
> its
> own keyword in the future, something like PREPARE or REQUIRE?
Well, either we do it in a language independent way, in which case this
would be too prescriptive, or
On 12/16/2012 08:44 PM, Andrew Dunstan wrote:
On 12/16/2012 01:37 AM, Peter Eisentraut wrote:
So in practice this might look like this:
CREATE FUNCTION foo(...) ... LANGUAGE plpythonu
AS $$
import x
import y
$$,
$$
real code here
$$;
Bleah.
It seems obscure to say the least.
Why not have
On 12/16/2012 01:37 AM, Peter Eisentraut wrote:
So in practice this might look like this:
CREATE FUNCTION foo(...) ... LANGUAGE plpythonu
AS $$
import x
import y
$$,
$$
real code here
$$;
Bleah.
It seems obscure to say the least.
Why not have something along the lines of plperl's on_init
On 12/16/2012 07:37 PM, Tom Lane wrote:
Hannu Krosing writes:
On further thought the function name should just be what it is defined
in postgresql, like this
CREATE FUNCTION foo(a,b,c) AS $$
import x
from __future__ import nex_cool_feature
def helper_function(x):
On 12/16/2012 07:44 PM, Tom Lane wrote:
Hannu Krosing writes:
On further thought the function name should just be what it is defined
in postgresql, like this
CREATE FUNCTION foo(a,b,c) AS $$
def foo(a,b,c):
BTW, how well will that play with overloaded function names? I don't
particula
Hannu Krosing writes:
>> On further thought the function name should just be what it is defined
>> in postgresql, like this
>> CREATE FUNCTION foo(a,b,c) AS $$
>> def foo(a,b,c):
BTW, how well will that play with overloaded function names? I don't
particularly care for saying that PL/Pyth
Hannu Krosing writes:
> On further thought the function name should just be what it is defined
> in postgresql, like this
> CREATE FUNCTION foo(a,b,c) AS $$
> import x
> from __future__ import nex_cool_feature
> def helper_function(x):
> ...
> def fo
On 12/16/2012 07:20 PM, Hannu Krosing wrote:
On 12/16/2012 07:03 PM, Tom Lane wrote:
Peter Eisentraut writes:
When you do
CREATE FUNCTION foo(...) ... LANGUAGE plpythonu
AS $$
source code here
$$;
it internally creates a "source file" that contains
---
def __plpython_procedure_foo_12345():
On 12/16/2012 07:03 PM, Tom Lane wrote:
Peter Eisentraut writes:
When you do
CREATE FUNCTION foo(...) ... LANGUAGE plpythonu
AS $$
source code here
$$;
it internally creates a "source file" that contains
---
def __plpython_procedure_foo_12345():
source code here
---
It would be useful to b
On 12/16/2012 07:37 AM, Peter Eisentraut wrote:
I'm going to use PL/Python as an example, but I would also like to know
if this could be applicable to other languages.
When you do
CREATE FUNCTION foo(...) ... LANGUAGE plpythonu
AS $$
source code here
$$;
it internally creates a "source file" t
Peter Eisentraut writes:
> When you do
> CREATE FUNCTION foo(...) ... LANGUAGE plpythonu
> AS $$
> source code here
> $$;
> it internally creates a "source file" that contains
> ---
> def __plpython_procedure_foo_12345():
> source code here
> ---
> It would be useful to be able to do somet
On Sun, 2012-12-16 at 10:20 +0100, Pavel Stehule wrote:
> Hello
>
> I understand to motivation, but proposed syntax is not too intuitive and
> robust
>
> can you do it in one function and call import only in first call?
Sometimes, but it's even less intuitive and robust.
--
Sent via pgsql-h
Hello
I understand to motivation, but proposed syntax is not too intuitive and robust
can you do it in one function and call import only in first call?
Regards
Pavel
2012/12/16 Peter Eisentraut :
> I'm going to use PL/Python as an example, but I would also like to know
> if this could be appl
I'm going to use PL/Python as an example, but I would also like to know
if this could be applicable to other languages.
When you do
CREATE FUNCTION foo(...) ... LANGUAGE plpythonu
AS $$
source code here
$$;
it internally creates a "source file" that contains
---
def __plpython_procedure_foo_123
29 matches
Mail list logo
