PostgreSQL
 sql >> Baza danych >  >> RDS >> PostgreSQL

Cofanie alokacji przygotowanych zapytań

Podczas zwalniania instrukcji zwracana jest wartość pg_query wskazuje na sukces lub nie, jak w przypadku każdego „oświadczenia o użyteczności”. W przypadku niepowodzenia powinien zwrócić false. Na przykład:

 if (!pg_query($cnx, "deallocate foobar")) {
   echo "Error deallocate: " . pg_last_error($cnx);
 }
 else {
  echo "deallocate successful";
 }

Wyświetla:

Zauważ, że nazwa instrukcji do cofnięcia alokacji nie może być otoczona pojedynczymi cudzysłowami, ponieważ jest to identyfikator, a nie literał ciągu. Jeśli trzeba go zamknąć z powodu problematycznych znaków, można to zrobić za pomocą pg_escape_identifier (php> =5.4.4)

Aby wyczyścić sesję, nie trzeba nawet iterować przygotowanych instrukcji i zwalniać ich pojedynczo, możesz zadzwonić DEALLOCATE ALL zamiast tego nadal z pg_query .

Jest też inna instrukcja, która więcej czyści w jednym zapytaniu:DISCARD ALL

Ponadto nic z tego nie jest konieczne, jeśli skrypt naprawdę odłącza się od postgresa, ponieważ przygotowane instrukcje są lokalne dla ich sesji nadrzędnej i umierają wraz z nią.

Wyraźne czyszczenie jest konieczne podczas korzystania z ponownego użycia połączenia między skryptami, zarówno z trwałymi połączeniami przez PHP (pg_pconnect ) lub pulę połączeń, np. pgBouncer (chociaż sam pooler może wywołać DISCARD ALL w zależności od konfiguracji).



  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. JPA 2.1 StoredProcedureQuery z PostgreSQL i REF_CURSORs

  2. lastInsertId nie działa w Postgresql

  3. Npgsql z Pgbouncer na Kubernetes - łączenie i keepalive

  4. Zwróć zero, jeśli nie znaleziono żadnego rekordu

  5. Jaka jest domyślna kolejność listy zwracanej przez wywołanie filtra Django?