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).
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)
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)'
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
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 wPROMPT1
:
–=
– 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, dlaczegopsql
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.
Ź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