PostgreSQL PL / Python：在virtualenv中调用存储过程(PostgreSQL PL/Python: call stored procedure in virtualenv)

PostgreSQL PL / Python：在virtualenv中调用存储过程(PostgreSQL PL/Python: call stored procedure in virtualenv)

当我在我的Python应用程序中调用PostgreSQL PL / Python存储过程时，它似乎在作为用户postgres运行的单独进程中执行。 到目前为止，这只会产生副作用，我必须使我的日志文件对我自己和数据库用户都可写，因此应用程序和存储过程都可以写入它。

然而，现在我开始使用virtualenv并在我的~/.virtualenvs/virt_env/lib/python2.7/site-packages/文件夹中添加了许多.pth文件， .pth文件将我的模块的路径添加到Python路径中。

执行存储过程时，用户postgres与我不在同一个虚拟环境中，因此存储过程找不到我的模块。 我可以在全局PostgreSQL环境中修改PYTHONPATH ，但每次切换虚拟环境时我都要改变它 - 这有点违背virtualenv的目的......

如何扩展存储过程的Python路径？

更新 ：

已经提出了类似的问题 ，并且解决了Postgres中修改PYTHONPATH环境变量的问题。 但是，似乎没有标准的方法来为PostgreSQL指定环境变量 ; 至少，它不是Mac OSX上可行的解决方案。

When I call a PostgreSQL PL/Python stored procedure in my Python application, it seems to be executed in a separate process running as user postgres. So far, this only had the side effect that I had to make my logfile writable for both myself and the database user, so application and stored procedure can both write to it.

Now however, I started using virtualenv and added a number of .pth files to my ~/.virtualenvs/virt_env/lib/python2.7/site-packages/ folder that add the paths to my modules to the Python path.

When the stored procedure is executed, user postgres is not in the same virtual environment as I am, so the stored procedure does not find my modules. I can modify PYTHONPATH in the global PostgreSQL environment, but I have to change that every time I switch virtual environments - which is kinda against the purpose of virtualenv...

How can I extend the Python path for stored procedures ?

UPDATE:

A similar question has been asked and the resolution there was to modify the PYTHONPATH environment variable in Postgres; however, it seems that there is no standard way to specify environment variables for PostgreSQL; at least, it is not a viable solution on Mac OSX.

最满意答案

事实证明，有一种方法可以做到这一点。 从版本1.6或那里开始，virtualenv附带了一个脚本activate_this.py ，可用于设置现有的解释器以访问该特定的virtualenv。

exec(open('/Some/VirtualEnv/Directory/myvirtualenv/bin/activate_this.py').read(), dict(__file__='/Some/VirtualEnv/Directory/myvirtualenv/bin/activate_this.py'))

并作为一个完全实现的plpython功能：

CREATE OR REPLACE FUNCTION workon(venv text) RETURNS void AS $BODY$ import os import sys if sys.platform in ('win32', 'win64', 'cygwin'): activate_this = os.path.join(venv, 'Scripts', 'activate_this.py') else: if not os.environ.has_key('PATH'): import subprocess p=subprocess.Popen('echo -n $PATH', stdout=subprocess.PIPE, shell=True) (mypath,err) = p.communicate() os.environ['PATH'] = mypath activate_this = os.path.join(venv, 'bin', 'activate_this.py') exec(open(activate_this).read(), dict(__file__=activate_this)) $BODY$ LANGUAGE plpythonu VOLATILE

（需要额外的PATH mungery，因为默认情况下，plpy在plpython os.environ中不可用 - activate_this.py已经检查了一个应该在下一个点发布时滚动的修复 （应该是1.11.7或1.12）

（主要来自https://gist.github.com/dmckeone/69334e2d8b27f586414a ）

There is a way to do it, as it turns out. Since version 1.6 or there abouts, virtualenv comes with a script activate_this.py, which can be used to set up an existing interpreter to access that particular virtualenv.

exec(open('/Some/VirtualEnv/Directory/myvirtualenv/bin/activate_this.py').read(), dict(__file__='/Some/VirtualEnv/Directory/myvirtualenv/bin/activate_this.py'))

And as a fully-realized plpython function:

CREATE OR REPLACE FUNCTION workon(venv text) RETURNS void AS $BODY$ import os import sys if sys.platform in ('win32', 'win64', 'cygwin'): activate_this = os.path.join(venv, 'Scripts', 'activate_this.py') else: if not os.environ.has_key('PATH'): import subprocess p=subprocess.Popen('echo -n $PATH', stdout=subprocess.PIPE, shell=True) (mypath,err) = p.communicate() os.environ['PATH'] = mypath activate_this = os.path.join(venv, 'bin', 'activate_this.py') exec(open(activate_this).read(), dict(__file__=activate_this)) $BODY$ LANGUAGE plpythonu VOLATILE

(The extra PATH mungery is needed since by default PATH isn't available in plpython os.environ - activate_this.py has a fix checked in that should roll w/ the next point release (which should be 1.11.7 or 1.12)

( taken mostly from https://gist.github.com/dmckeone/69334e2d8b27f586414a )