Du kan använda i stort sett alla Python-bibliotek i en PL/Python-lagrad procedur eller trigger.
Se PL/Python-dokumentationen .
Koncept
Den avgörande punkten att förstå är att PL/Python är CPython (i PostgreSQL till och med 9.3 i alla fall); den använder exakt samma tolk som den normala fristående Python gör, den laddar bara in den som ett bibliotek i PostgreSQL-backupen. Med några begränsningar (som beskrivs nedan), om det fungerar med CPython fungerar det med PL/Python.
Om du har flera Python-tolkar installerade på ditt system - versioner, distributioner, 32-bitars vs 64-bitars etc - kan du behöva se till att du installerar tillägg och bibliotek till rätt när du kör distutils skript, etc, men det är om det.
Eftersom du kan ladda vilket bibliotek som helst som är tillgängligt för systemet Python finns det ingen anledning att tro att NLTK skulle vara ett problem om du inte vet att det kräver saker som trådning som egentligen inte rekommenderas i en PostgreSQL-backend. (Visst nog, jag provade det och det "bara fungerade", se nedan).
En möjlig oro är att startoverheaden för något som NLTK kan vara ganska stor, du vill förmodligen förladda PL/Python i postmastern och importera modulen i din installationskod så att den är klar när backends startar. Förstå att postmastern är den överordnade processen som alla andra backends fork() från, så om postmastern förladdar något är det tillgängligt för backends med kraftigt reducerade omkostnader. Testa prestanda åt båda håll.
Säkerhet
Eftersom du kan ladda godtyckliga C-bibliotek via PL/Python och eftersom Python-tolken inte har någon riktig säkerhetsmodell, plpythonu är ett "otillförlitligt" språk. Skript har full och obegränsad tillgång till systemet som postgres användare och kan ganska enkelt kringgå åtkomstkontroller i PostgreSQL. Av uppenbara säkerhetsskäl betyder detta att PL/Python-funktioner och utlösare endast kan skapas av superanvändaren, även om det är ganska rimligt att GRANT normala användare möjligheten att köra noggrant skrivna funktioner som installerades av superanvändaren.
Fördelen är att du kan göra i stort sett allt du kan göra i normal Python, med tanke på att Python-tolkens livstid är den för databasanslutningen (sessionen). Trådning rekommenderas inte, men det mesta är bra.
PL/Python-funktioner måste skrivas med noggrann ingångssanering, måste ställa in search_path när man anropar SPI för att köra frågor, etc. Detta diskuteras mer i manualen.
Begränsningar
Långvariga eller potentiellt problematiska saker som DNS-uppslagningar, HTTP-anslutningar till fjärrsystem, SMTP-postleverans etc bör i allmänhet göras från ett hjälpskript med LISTEN och NOTIFY snarare än ett in-backend jobb för att bevara PostgreSQL:s prestanda och undvika att hindra VACUUM med många långa transaktioner. Du kan göra dessa saker i backend, det är bara ingen bra idé.
Du bör undvika att skapa trådar inom PostgreSQL-backend.
Försök inte ladda något Python-bibliotek som laddar libpq C bibliotek. Detta kan orsaka alla möjliga spännande problem med backend. När du pratar med PostgreSQL från PL/Python använd SPI-rutinerna, inte ett vanligt klientbibliotek.
Gör inte mycket långvariga saker i backend, du kommer att orsaka vakuumproblem.
Ladda inte något som kan ladda en annan version av ett redan laddat inbyggt C-bibliotek - säg en annan libcrypto, libssl, etc.
Skriv inte direkt till filer i PostgreSQL-datakatalogen, någonsin .
PL/Python-funktioner körs som postgres systemanvändare på operativsystemet, så att de inte har tillgång till saker som användarens hemkatalog eller filer på klientsidan av anslutningen.
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:Prova. Så länge Python-tolken PostgreSQL använder för plpython har nltks beroenden installerade kommer det att fungera bra.
Obs
PL/Python är CPython, men jag skulle gärna se ett PyPy-baserat alternativ som kan köra opålitlig kod med PyPys sandlådefunktioner.