2011-07-21 8 views
12

Mam fragment kodu Pythona, który współdziała z bazą danych PostgreSQL za pośrednictwem psycopg.psycopg - Pobierz sformatowany sql zamiast wykonywania

Cała literatura ostrzega przed formatowaniem sql przez siebie i zaleca, aby kierowca to zrobił. Np .:

cur.execute('select name, age from people where name = %s;', ('ann',)) 

Sterownik następnie formatuje ciąg znaków SQL. Powiedzmy, że nie chcę niczego wykonywać, ale chcę tylko w pełni sformatowany ciąg sql. Czy istnieje możliwość uzyskiwania tego sformatowanego sql w module psycopg?

Odpowiedz

14

ty wold funkcji Użyj curs.mogrify():

SQLstring = curs.mogrify('select name, age from people where name = %s;', ('ann',)) 
+1

Należy zauważyć, że autor psycopg ma [stwierdził] (http://permalink.gmane.org/gmane.comp.python.db.psycopg.devel/4775), że mogrify powinien być używany tylko do celów debugowania. –

+0

Ta funkcja mogrify wymaga DB API 2.0, http://initd.org/psycopg/docs/cursor.html#cursor.mogrify. –

+0

Prawdopodobnie wynik tego jest dobry dla poprzedzania 'EXPLAIN' i wykonywania, aby zobaczyć plan wykonania? –

0

edytuj: wygląda na to, że poniższe informacje nie są całkiem poprawne, psycopg nie jest używać PQexecParams, ale planuje (zobacz mój komentarz poniżej). Pozostawiając odpowiedź, ponieważ jest to użyteczna abstrakcja i jest prawdziwa dla większości sparametryzowanych zapytań, najwyraźniej nie jest to jeszcze psycopg2.


W rzeczywistości sterownik nie formatuje łańcucha. To, czego używasz, nazywa się sparametryzowanym zapytaniem: ciąg sql i parametry są wysyłane "przez przewód" do postgresów dokładnie tak, jak je określiłeś, postgres parsuje łańcuch szablonu, a następnie wstawia parametry do drzewa analizy. W ten sposób parametry nigdy nie muszą być dekodowane, więc nie ma żadnych błędów kodowania, trzasków ani wstrzyknięć. OTOH, to znaczy, że w żadnym punkcie kodu nie ma czegoś takiego jak procedura formatowania, której szukasz.

Aby uzyskać więcej informacji, zobacz "PQexecParams" w dokumentacji libpq - libpq jest biblioteką interfejsu klienta PostgreSQL.

+0

wow, ciekawego. To musi oznaczać, że w przypadku sparametryzowanych zapytań, jeśli pojawia się błąd składni sql, musi to być sam kod, a nie jakieś dziwne znaki w wartości ciągu? –

+0

W ten sposób zawsze zakładałem, że wszystko działa - i * możesz * bezpiecznie traktować to tak, jakby to działało. Jednak właśnie skończyłem sprawdzanie źródła psycopg i wygląda na to, że * oni * obsługują formatowanie szablonów i przechodzenie znaków po stronie klienta ([patrz repozytorium git] (https://dndg.it/cgi-bin/gitweb. cgi? p = public/psycopg2.git; a = blob; f = psycopg/cursor_type.c; h = 717cf9ccad879a2aa33b71db9a0029be4932ce4c; hb = HEAD # l388)). Chociaż wygląda na to, że pracują nad wykorzystaniem PQexecParams, gdzie to możliwe - zobacz [this] (http://archives.postgresql.org/psycopg/2011-02/msg00076.php). –

+1

Tylko rzucić trochę światła .. PQexecParams ma pewne ograniczenia, więc formatowanie zapytania po stronie klienta pozostanie. Głównym powodem, dla którego mogrify może być używany tylko do debugowania, jest to, że nie możemy zagwarantować, że jego wynikiem zawsze będzie zapytanie _exact_ wysyłane do backendu (na przykład, jeśli przełożymy się na przygotowanie zapytania i użycie PQexecParams). – fog

Powiązane problemy