Psql III

Tips & Tricks – Poradnik psql cz. III. – dostosowanie konfiguracji z plikiem .psqlrc

W tej części serii o psql – interaktywnym terminalu do bazy PostgreSQL – zajmiemy się, zgodnie z zapowiedziami w poprzednich artykułach, konfiguracją przy pomocy pliku  .psqlrc. Pokażemy, które opcje mogą być szczególnie przydatne w codziennej pracy, a także zwrócimy uwagę na nowości wprowadzone wraz z pojawieniem się najnowszej wersji bazy PostgreSQL 11.1. Plik konfiguracyjny psqlrc […]

W tej części serii o psql – interaktywnym terminalu do bazy PostgreSQL – zajmiemy się, zgodnie z zapowiedziami w poprzednich artykułach, konfiguracją przy pomocy pliku  .psqlrc. Pokażemy, które opcje mogą być szczególnie przydatne w codziennej pracy, a także zwrócimy uwagę na nowości wprowadzone wraz z pojawieniem się najnowszej wersji bazy PostgreSQL 11.1.

Plik konfiguracyjny psqlrc

Systemy unixopodobne, do których zaliczane są również systemy oparte o jądro Linux, odziedziczyły konwencję nazewniczą plików konfiguracyjnych z sufiksem rc. Jest to zaszłość jeszcze z zamierzchłych (jak na szybkość rozwoju technologii informatycznych) czasów systemu CTSS, kiedy komendy przechowywały informacje o tym, jakie polecenia wykonać, właśnie w formie plików runcom, czyli run commands (ang. wykonaj polecenia), które następnie w systemie Unix zostały skrócone do rc.

Psql pod tym względem, jak widać, nie odstaje od normy. W jego przypadku istnieją dwa pliki konfiguracyjne – ogólny systemowy, który powinien się znajdować w katalogu konfiguracyjnym bazy oraz plik odpowiadający poszczególnym użytkownikom, który powinien się znajdować w katalogu domowym danego użytkownika. My skupimy się na pliku użytkownika oraz komendach i opcjach, które będą najbardziej przydatne w trybie interaktywnym.

Zmienne środowiskowe psql

W poprzednim artykule z tej serii wspominaliśmy już o zmiennych środowiskowych. Dziś zwrócimy uwagę na kolejną istotną zmienną, która odpowiada za wyświetlanie wyników poleceń na ekranie w sposób wygodny do interaktywnego przeglądania – PAGER, czyli po polsku „program do paginacji”.

W większości dystrybucji zmienna ta wskazuje na program less lub jego starszy odpowiednik more. Nowszy program oferuje zdecydowanie więcej możliwości, co stara się zakomunikować przez swoją nazwę (ang. less is more) ze specyficznym poczuciem humoru.

Psql korzysta z tej zmiennej w celu określenia, w jaki sposób wyświetlić, np. rezultat zapytania. W przypadku gdy tabela ma wiele kolumn, a PAGER nie wskazuje na dobrze skonfigurowany paginator, może to doprowadzić do wyświetlenia informacji w sposób nieczytelny (oraz frustracji użytkownika psql).

zly-pager

Naszym zdaniem najlepszym wyborem jest skorzystanie z programu less z dodatkowymi opcjami, które również można podać przez zmienną środowiskową. Następujące komendy najlepiej umieścić w pliku .profile.

export PAGER='less' # zmiana domyślnego paginatora
export LESS='-iSFx4' # dodatkowe opcje, z których skorzysta less

Opcje programu less, z których korzystamy:

-i lub --ignore-case powoduje, że wyszukiwanie ignoruje wielkość liter, to jest litery małe i wielkie są uważane za identyczne;
-S lub --chop-long-lines powoduje, że linie dłuższe niż szerokość ekranu są ucinane, a nie zawijane;
-F lub --quit-if-one-screen powoduje, że less automatycznie kończy pracę, jeśli cały plik da się wyświetlić na jednym ekranie;
-xn,...lub --tabs=n,... kontroluje pozycje tabulacji (odległość liczoną w spacjach) – w tym przypadku 4 i jej wielokrotności.
Należy pamiętać, że ta zmiana będzie odnosić się do wszystkich programów, które korzystają z tej zmiennej. Jeśli nie jest to zachowanie pożądane, możemy skorzystać z dedykowanej zmiennej dla psql, która została dodana z wersją PostgreSQL 11 – PSQL_PAGER. W przypadku gdy nowsza zmienna nie jest zdefiniowana, program skorzysta z ustawień systemowych w PAGER.

export PAGER='more' # ustawienie globalne
export PSQL_PAGER='less' # ustawienie dla psql (od wersji 11)

dobry-pager

Komendy konfigurujące psql

Teraz możemy już przejść bezpośrednio do modyfikacji pliku ~/.psqlrc, czyli konfiguracji dla naszego użytkownika.

Pager

Dla pełności zwróćmy jeszcze uwagę na ustawienia związane z wyświetlaniem – zmęczonym tym tematem obiecuję, że krótko ;-)
psql dostarcza własną zmienną pager domyślnie przyjmującą wartość on, która kontroluje, czy w ogóle chcemy korzystać z paginacji. Dość nieintuicyjnie domyślna konfiguracja nie korzysta z zewnętrznych programów każdorazowo, a jedynie wtedy, gdy wyniki nie mieszczą się na ekranie. Możemy to zmienić, ustawiając tam wartość always. W przypadku, gdyby paginacja była niepożądana, można ustawić wartość off – a może się tak zdarzyć na przykład przy użyciu multipleksera terminala z dobrym wsparciem dla przewijania.

\pset pager always

Kontrola wyświetlania znacznika pustych danych –null

Domyślnie wartość NULL w rezultatach jest prezentowana jako znak spacji, dokładnie tak samo, jak pusty napis. Aby wyniki były bardziej czytelne, możemy zmienić sposób wyświetlania wartości NULL, na przykład w ten sposób:

\pset null '(null)'

null

Kontrola sposobu autouzupełniania – COMP_KEYWORD_CASE

Sposób pisania kwerend do bazy danych zależy od osoby, która je pisze. Jedni wolą korzystać z wielkich liter dla składni SQL, inni preferują pisanie małymi literami. psql wychodzi naprzeciw obu tym grupom użytkowników i pozwala na ułatwianie pisania w sposób odpowiadający własnym upodobaniom.

\set COMP_KEYWORD_CASE upper # dla tych, którzy wolą wielkie litery
\set COMP_KEYWORD_CASE lower # dla tych, którzy wolą małe litery

keyword-case

Zmiana zachętki (prompt)

Sposób wyświetlania zachętki powłoki psql również można dopasować do własnych potrzeb. O domyślnych ustawieniach wspominaliśmy już w części pierwszej. Teraz opiszemy nieco dokładniej, jak to działa.

Za format wyświetlania prompta odpowiadają trzy zmienne:

PROMPT1 – kontroluje wyświetlanie w domyślnym, normalnym trybie pracy, kiedy zachęca do wydania następnej komendy;

PROMPT2 – odpowiada za zachęcanie, kiedy wprowadzanie komendy jeszcze się nie zakończyło (np. zapomnieliśmy o średniku na końcu kwerendy), ale przeszliśmy do nowej linii;

PROMPT3 – to specjalna zachętka wykorzystywana przy wywołaniu polecenia COPY FROM STDIN, a poszczególne wiersze są wprowadzane z terminala.
Aby sprawdzić, jakie są domyślne wartości, można skorzystać z komendy \echo. Dla użytkownika postgres standardowo wygląda to tak:

\echo :PROMPT1
%/%R%#
--- wartość PROMPT2 identyczna z PROMPT1
\echo :PROMPT3 
>>

Spróbujemy teraz rozszyfrować znaczenie poszczególnych sekwencji sterujących zachętką.

  • %/ – wyświetla nazwę aktualnie połączonej bazy;
  • %R – odpowiada za wyświetlanie informacji związanych ze stanem i przyjmuje następujące wartości:
    * jeśli jesteśmy w PROMPT1:
    = – w warunkach normalnych;
    ^ – w trybie pojedynczej linii, gdzie znak nowego wiersza zachowuje się jak ;;
    ! – kiedy sesja zostanie odłączona od bazy danych (np. gdy \connect zakończy się niepowodzeniem);
    * jeśli jest częścią PROMPT2, mówi, dlaczego psql oczekuje na dalszą część komendy (najczęściej występujące):
    - – gdy polecenie nie zostało zakończone;
    ' – gdy nie zamknęliśmy napisu;
    " – gdy nie zamknęliśmy identyfikatora;
    ( – gdy nie zamknęliśmy otwartego wcześniej nawiasu.

Możemy teraz przejść do wprowadzania zmian. Dobrym punktem wyjścia będzie dodanie informacji dotyczących konfiguracji serwera, do którego jesteśmy podłączeni, na co składać się będzie:

  • nazwa użytkownika;
  • pełna nazwa hosta (razem z nazwą domeny);
  • port, na którym nasłuchuje baza danych.

Po kolei odpowiadać za to będą parametry %n; %M; %>. Składając to w całość, można by dodać do pliku konfiguracyjnego np.:

\set PROMPT1 '%n@%M:%> %/%R%#'

To prowadzi do następującego rezultatu w moim środowisku testowym:

postgres=# \set PROMPT1 '%n@%M:%> %/%R%#'
postgres@[local]:5432 postgres=#

Jak widać, zmiana jest natychmiastowa – następna zachętka wygląda zgodnie z oczekiwaniami.
Warto zwrócić uwagę, że [local] nie jest w tym wypadku nazwą hosta. Jeśli połączenie z bazą następuje przez gniazdo (ang. socket), zostaniemy o tym poinformowani właśnie w taki sposób.
Więcej opcji można znaleźć w oficjalnej dokumentacji PostgreSQL. Szczególną uwagę zwracam jednak na następujące opcje:

  • %x – wyświetla informacje związane ze statusem transakcji;
  • %l – numer linii w bieżącym poleceniu (może być przydatne przy debugowaniu zapytań, szczególnie przy ustawieniu również jako część PROMPT2).

Konfiguracja historii poleceń ~/.psql_history

Mając dodatkowe informacje na temat hosta, z którym jesteśmy połączeni w prompcie, możemy pójść o krok dalej i podzielić plik historii wydanych poleceń, w taki sposób, aby polecenia z różnych baz trafiały do różnych plików.

W tym celu skorzystamy ze zmiennej psql:DBNAME oraz zmiennej kontrolującej nazwę pliku historii. Istnieją również inne zmienne, z których można skorzystać jak np. :HOST; :PORT; :USER oraz wiele innych. My jednak skupimy się na razie na jednym parametrze.

\set HISTFILE ~/.psql_history- :DBNAME
-- możemy od razu sprawdzić ustawioną wartość
\echo :HISTFILE
~/.psql_history-postgres

Kolejnym istotnym parametrem w przypadku pliku historii jest ilość przechowywanych poleceń. To ustawienie znajduje się pod kontrolą zmiennej HISTSIZE. Domyślnym ustawieniem jest 500 poleceń. Zmiana tej wartości przy pomocy:

\set HISTSIZE 2000

powinna zaspokoić potrzeby większości administratorów.

Podsumowanie

Psql jest bardzo wszechstronnym klientem i posiada ogromne możliwości konfiguracyjne, które powinny pozwolić każdemu na dopasowanie jego działania do własnych potrzeb. Najważniejsze jest bowiem to, by wykorzystać 100% przydatnych opcji, a nie walczyć z domyślnym zachowaniem, które może nie pokrywać potrzeb wszystkich użytkowników. Mamy nadzieję, że przedstawiając możliwości tego programu, zachęciliśmy do zajrzenia do pliku konfiguracyjnego i do indywidualnego dostosowania tego narzędzia.

psql – Tips & Tricks
psql – Tips & Tricks II
psql – Tips & Tricks III – ten materiał

Źródła:
dokumentacja wersji 10: https://www.postgresql.org/docs/10/app-psql.html
dokumentacja wersji 11: https://www.postgresql.org/docs/11/app-psql.html

Autorzy

Artykuły na blogu są pisane przez osoby z zespołu EuroLinux. 80% treści zawdzięczamy naszym developerom, pozostałą część przygotowuje dział sprzedaży lub marketingu. Dokładamy starań, żeby treści były jak najlepsze merytorycznie i językowo, ale nie jesteśmy nieomylni. Jeśli zauważysz coś wartego poprawienia lub wyjaśnienia, będziemy wdzięczni za wiadomość.