概念

要理解的关键点是 PL / Python CPython （在PostgreSQL中直到并包括9.3，无论如何）;它使用与普通独立Python完全相同的解释器，它只是将它作为库加载到PostgreSQL支持的。有一些限制（如下所述），如果它适用于CPython，则可以使用PL / Python。

如果您的系统上安装了多个Python解释器 - 版本，发行版，32位与64位等 - 您可能需要确保在运行distutils脚本等时将扩展和库安装到正确的解释器中，但这就是它。

由于你可以加载系统Python可用的任何库，所以没有理由认为NLTK会成为一个问题，除非你知道它需要像PostgreSQL后端中没有真正推荐的线程之类的东西。（果然，我尝试了它并且它“正常工作”，见下文）。

一个可能的问题是像NLTK这样的东西的启动开销可能很大，你可能想在postmaster中预加载PL / Python并在你的设置代码中导入模块，以便在后端启动时准备就绪。了解postmaster是所有其他后端fork()的父进程，因此如果postmaster预加载了后端可用的内容，并且开销大大减少。无论哪种方式测试性能。

安全

因为您可以通过PL / Python加载任意C库，并且由于Python解释器没有真正的安全模型，plpythonu是一种“不可信”的语言。脚本具有对postgres用户的完全和不受限制的系统访问权限，并且可以简单地绕过PostgreSQL中的访问控制。出于明显的安全原因，这意味着PL / Python函数和触发器可能只能由超级用户创建，尽管GRANT普通用户能够运行精心编写的已安装函数是非常合理的由超级用户。

好处是你可以在普通的Python中做很多事情，记住Python解释器的生命周期是数据库连接（会话）的生命周期。不建议使用线程，但大多数其他事情都没问题。

PL / Python函数必须在仔细的输入卫生条件下编写，在调用SPI运行查询时必须设置search_path等。本手册对此进行了详细讨论。

限制

DNS查找，远程系统的HTTP连接，SMTP邮件传递等长期运行或可能存在问题的事情通常应该通过使用LISTEN和NOTIFY的帮助程序脚本完成，而不是在后端作业是为了保留PostgreSQL的性能并避免因许多长事务而妨碍VACUUM。你可以在后端做这些事情，这不是一个好主意。

您应该避免在PostgreSQL后端中创建线程。

不要尝试加载任何将加载libpq C库的Python库。这可能会导致后端出现各种令人兴奋的问题。当从PL / Python与PostgreSQL交谈时，使用SPI例程而不是常规客户端库。

不要在后端做很长时间的事情，否则会造成真空问题。

不要加载任何可能加载已加载的本机C库的不同版本的东西 - 例如不同的libcrypto，libssl等。

不要直接写入PostgreSQL数据目录中的文件，永远。

PL / Python函数在操作系统上作为postgres系统用户运行，因此他们无法访问用户主目录或连接客户端文件等内容。

测试结果

$ yum install python-nltk python-nltk
$ psql -U postgres regress

regress=# CREATE LANGUAGE plpythonu;

regress=# CREATE OR REPLACE FUNCTION nltk_word_tokenize(word text) RETURNS text[] AS $$
          import nltk
          return nltk.word_tokenize(word)
          $$ LANGUAGE plpythonu;

regress=# SELECT nltk_word_tokenize('This is a test, it''s going to work fine');
              nltk_word_tokenize               
-----------------------------------------------
 {This,is,a,test,",",it,'s,going,to,work,fine}
(1 row)

所以，正如我所说：试试吧。只要Python解释器PostgreSQL用于plpython安装了nltk的依赖项，它就可以正常工作。

注意

PL / Python是CPython，但我很想看到一个基于PyPy的替代品，可以使用PyPy的沙箱功能运行不受信任的代码。

可以在Postgres Python存储过程中使用NLTK

1 个答案:

概念

安全

限制

测试结果

注意