Możesz użyć praktycznie dowolnej biblioteki Pythona w procedurze składowanej lub wyzwalaczu PL/Python.
Zobacz dokumentację PL/Pythona .
Koncepcje
Kluczowym punktem do zrozumienia jest to, że PL/Python jest Cpython (w każdym razie w PostgreSQL do wersji 9.3 włącznie); używa dokładnie tego samego interpretera, co normalny samodzielny Python, po prostu ładuje go jako bibliotekę do wspieranego przez PostgreSQL. Z kilkoma ograniczeniami (opisanymi poniżej), jeśli działa z CPythonem, działa z PL/Pythonem.
Jeśli masz zainstalowanych wiele interpreterów Pythona w swoim systemie – wersje, dystrybucje, 32-bitowe, 64-bitowe itp. – być może będziesz musiał upewnić się, że instalujesz rozszerzenia i biblioteki we właściwych miejscach podczas uruchamiania skryptów distutils itp., ale to jest o tym.
Ponieważ możesz załadować dowolną bibliotekę dostępną do systemu Python, nie ma powodu sądzić, że NLTK będzie problemem, chyba że wiesz, że wymaga takich rzeczy, jak wątkowanie, które nie są tak naprawdę zalecane w backendzie PostgreSQL. (Oczywiście, spróbowałem i "po prostu zadziałało", patrz poniżej).
Jednym z możliwych problemów jest to, że narzut związany z uruchamianiem czegoś takiego jak NLTK może być dość duży, prawdopodobnie chcesz wstępnie załadować PL/Pythona w postmasterze i zaimportować moduł w kodzie instalacyjnym, aby był gotowy po uruchomieniu backendów. Zrozum, że postmaster jest procesem nadrzędnym, który wszystkie inne backendy fork() od, więc jeśli postmaster coś wstępnie ładuje, jest to dostępne dla backendów ze znacznie zmniejszonymi kosztami ogólnymi. Przetestuj wydajność w dowolny sposób.
Bezpieczeństwo
Ponieważ możesz ładować dowolne biblioteki C przez PL/Pythona i ponieważ interpreter Pythona nie ma prawdziwego modelu bezpieczeństwa, plpythonu jest „niezaufanym” językiem. Skrypty mają pełny i nieograniczony dostęp do systemu jako postgres użytkownika i może po prostu ominąć kontrolę dostępu w PostgreSQL. Z oczywistych względów bezpieczeństwa oznacza to, że funkcje i wyzwalacze PL/Python mogą być tworzone tylko przez administratora, chociaż rozsądne jest GRANT normalnym użytkownikom możliwość uruchamiania starannie napisane funkcje, które zostały zainstalowane przez administratora.
Plusem jest to, że możesz zrobić prawie wszystko, co możesz zrobić w normalnym Pythonie, pamiętając, że czas życia interpretera Pythona jest związany z połączeniem z bazą danych (sesja). Nawlekanie nie jest zalecane, ale większość innych rzeczy jest w porządku.
Funkcje PL/Pythona muszą być napisane z zachowaniem starannych warunków sanitarnych, należy ustawić search_path podczas wywoływania SPI w celu uruchomienia zapytań itp. Jest to omówione więcej w podręczniku.
Ograniczenia
Długotrwałe lub potencjalnie problematyczne rzeczy, takie jak wyszukiwanie DNS, połączenia HTTP ze zdalnymi systemami, dostarczanie poczty SMTP itp., powinny być wykonywane ze skryptu pomocniczego za pomocą LISTEN i NOTIFY zamiast zadania wewnątrzzaplecza, aby zachować wydajność PostgreSQL i uniknąć utrudnień VACUUM z wieloma długimi transakcjami. Możesz robić te rzeczy w backendzie, to po prostu nie jest świetny pomysł.
Powinieneś unikać tworzenia wątków w backendzie PostgreSQL.
Nie próbuj ładować żadnej biblioteki Pythona, która załaduje libpq Biblioteka C. Może to spowodować wiele ekscytujących problemów z backendem. Podczas rozmowy z PostgreSQL z PL/Python używaj procedur SPI, a nie zwykłej biblioteki klienta.
Nie rób zbyt długotrwałych rzeczy w backendzie, spowodujesz problemy z próżnią.
Nie ładuj niczego, co może załadować inną wersję już załadowanej natywnej biblioteki C - powiedz inne libcrypto, libssl itp.
Nie pisz bezpośrednio do plików w katalogu danych PostgreSQL, nigdy .
Funkcje PL/Pythona działają jako postgres użytkownika systemowego w systemie operacyjnym, więc nie mają dostępu do takich rzeczy, jak katalog domowy użytkownika lub pliki po stronie klienta połączenia.
Wynik testu
$ 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)
A więc, jak powiedziałem:spróbuj. Dopóki interpreter Pythona, którego PostgreSQL używa dla plpython, ma zainstalowane zależności nltk, będzie działał dobrze.
Uwaga
PL/Python to CPython, ale chciałbym zobaczyć alternatywę opartą na PyPy, która może uruchamiać niezaufany kod przy użyciu funkcji piaskownicy PyPy.
