Du kan bruge stort set ethvert Python-bibliotek i en PL/Python-lagret procedure eller trigger.
Se PL/Python-dokumentationen .
Koncepter
Det afgørende punkt at forstå er, at PL/Python er CPython (i PostgreSQL til og med 9.3 i hvert fald); den bruger nøjagtig den samme fortolker, som den normale selvstændige Python gør, den indlæser den bare som et bibliotek i PostgreSQL-støttet. Med nogle få begrænsninger (som beskrevet nedenfor), hvis det virker med CPython, virker det med PL/Python.
Hvis du har flere Python-fortolkere installeret på dit system - versioner, distributioner, 32-bit vs 64-bit osv. - skal du muligvis sørge for, at du installerer udvidelser og biblioteker i den rigtige, når du kører distutils scripts osv., men det er om det.
Da du kan indlæse ethvert bibliotek, der er tilgængeligt for systemet Python, er der ingen grund til at tro, at NLTK ville være et problem, medmindre du ved, at det kræver ting som threading, der ikke rigtig anbefales i en PostgreSQL-backend. (Ja, jeg prøvede det, og det "virkede bare", se nedenfor).
En mulig bekymring er, at opstartsomkostningerne for noget som NLTK kan være ret store, du vil sandsynligvis forudindlæse PL/Python i postmasteren og importere modulet i din opsætningskode, så det er klar, når backends starter. Forstå, at postmasteren er den overordnede proces, som alle de andre backends fork() fra, så hvis postmesteren forudindlæser noget, er det tilgængeligt for backends med stærkt reducerede omkostninger. Test ydeevne på begge måder.
Sikkerhed
Fordi du kan indlæse vilkårlige C-biblioteker via PL/Python, og fordi Python-fortolkeren ikke har nogen reel sikkerhedsmodel, plpythonu er et "upålidelig" sprog. Scripts har fuld og ubegrænset adgang til systemet som postgres bruger og kan ganske enkelt omgå adgangskontrol i PostgreSQL. Af indlysende sikkerhedsmæssige årsager betyder dette, at PL/Python-funktioner og triggere kun må oprettes af superbrugeren, selvom det er ret rimeligt at GRANT normale brugere muligheden for at køre omhyggeligt skrevne funktioner, der blev installeret af superbrugeren.
Fordelen er, at du kan gøre stort set alt, hvad du kan gøre i normal Python, idet du husker på, at Python-fortolkerens levetid er databaseforbindelsen (sessionen). Trådning anbefales ikke, men de fleste andre ting er i orden.
PL/Python-funktioner skal skrives med omhyggelig input-sanering, skal indstille search_path når man kalder SPI'en til at køre forespørgsler osv. Dette er beskrevet mere i manualen.
Begrænsninger
Længerevarende eller potentielt problematiske ting som DNS-opslag, HTTP-forbindelser til fjernsystemer, SMTP-postlevering osv. bør generelt udføres fra et hjælpescript ved hjælp af LISTEN og NOTIFY snarere end et in-backend job for at bevare PostgreSQL's ydeevne og undgå at hæmme VACUUM med mange lange transaktioner. Du kan gøre disse ting i backend, det er bare ikke en god idé.
Du bør undgå at oprette tråde i PostgreSQL-backend.
Forsøg ikke at indlæse et Python-bibliotek, der indlæser libpq C bibliotek. Dette kan forårsage alle mulige spændende problemer med backend. Når du taler til PostgreSQL fra PL/Python, skal du bruge SPI-rutinerne, ikke et almindeligt klientbibliotek.
Gør ikke meget langvarige ting i backend, du vil forårsage vakuumproblemer.
Indlæs ikke noget, der kan indlæse en anden version af et allerede indlæst indbygget C-bibliotek - sig en anden libcrypto, libssl osv.
Skriv ikke direkte til filer i PostgreSQL-datamappen, nogensinde .
PL/Python-funktioner kører som postgres systembruger på operativsystemet, så de ikke har adgang til ting som f.eks. brugerens hjemmemappe eller filer på klientsiden af forbindelsen.
Testresultat
$ 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)
Så som sagt:Prøv det. Så længe Python-fortolkeren PostgreSQL bruger til plpython, har nltks afhængigheder installeret, vil det fungere fint.
Bemærk
PL/Python er CPython, men jeg ville elske at se et PyPy-baseret alternativ, der kan køre upålidelig kode ved hjælp af PyPys sandkassefunktioner.