On Fri, Dec 28, 2012 at 7:09 AM, Hannu Krosing ha...@krosing.net 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
On Fri, Dec 28, 2012 at 12:24 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
2012/12/28 Peter Eisentraut pete...@gmx.net:
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
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
2012/12/28 Peter Eisentraut pete...@gmx.net:
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:
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
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
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
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
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,c):
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(x):
2012/12/17 Peter Eisentraut pete...@gmx.net:
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
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
Hannu Krosing ha...@krosing.net 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
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 pete...@gmx.net:
I'm going to use PL/Python as an example, but I would also like to know
if this
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
Peter Eisentraut pete...@gmx.net 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
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
On 12/16/2012 07:03 PM, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net 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
On 12/16/2012 07:20 PM, Hannu Krosing wrote:
On 12/16/2012 07:03 PM, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
When you do
CREATE FUNCTION foo(...) ... LANGUAGE plpythonu
AS $$
source code here
$$;
it internally creates a source file that contains
---
def
Hannu Krosing ha...@2ndquadrant.com 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):
...
Hannu Krosing ha...@2ndquadrant.com 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
On 12/16/2012 07:44 PM, Tom Lane wrote:
Hannu Krosing ha...@2ndquadrant.com 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
On 12/16/2012 07:37 PM, Tom Lane wrote:
Hannu Krosing ha...@2ndquadrant.com 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
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 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
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 we
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 here
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
28 matches
Mail list logo
