On Jul 24, 2009, at 7:08 PM, Stuart Bishop wrote:
I'm not particularly interested in Python 3.x support yet (we are
still back on 2.4, soon to hop to 2.5 or 2.6. For us 3.1 is probably
2 years away at the earliest). I am interested in improved plpython
though.
Two years would hopefully be enough time to work out most of the new
bugs. =)
This way I can pass in a mock object. This is also useful outside of
the test suite - the same module can be used as a stored procedure
or by your Python application - your web application can use the
same validators as your check constraints for instance.
Hmm.
import sys
sys.modules["Postgres"] = mock_pg_module
Would that not suffice?
I'd like a way to avoid initialization on module import if possible.
Calling an initialization function after module import, if it
exists, would do this.
CREATE FUNCTION foo(int) RETURNS in LANGUAGE plpythonu AS
$python$
[initialization on module import]
def pg_init(pg):
[initialization after module import]
def pg_main(pg, i):
return i
$python$;
I do like this idea. However, it may already be possible under the
current design with some explicit main() management:
CREATE ...
$python$
import Postgres
def usual(*args):
...
def init(*args):
global main
...
main = usual
return usual(*args)
main = init
$python$;
Perhaps ugly, but I imagine a construct could be created to clean it up:
CREATE ...
$python$
import Postgres
def usual(*args):
...
def init(*args):
...
return usual(*args)
main = call_once_then(init, lambda: globals()['main'] = usual)
$python$;
Hmm, still ugly tho, no?
Well, the above examples aren't actually consistent with your design,
but perhaps it achieves the desired result?
I tend to dislike magic function names, but perhaps it is the most
usable solution.
Indeed.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
