Pętle cd.

Miałem napisać o pętlach, w poprzednim wpisie, ale materiał jest na tyle obszerny że postanowiłem to przenieść i poświęcić im cały wpis. No to jedziemy.

Pętle jak nam ładnie pokazuje manual:

[ <<label>> ]
LOOP
    statements
END LOOP [ label ];

Proste co? A teraz, krótki opis, otóż każda pętla może zostać „nazwana”, czyli posiadać tzw. label ( z ang. etykietę ), po co? Po to gdy będziemy chcieli zakończyć pętle, a będziemy mieli zagnieżdżenie pętel, to w przypadku chęci wyjścia całkiem z wszystkich pętli, wystarczy podać nazwę pętli wyżej. Służy nam temu polecenie:

EXIT [ label ] [ WHEN boolean-expression ];

Dlaczego nie RETURN a EXIT? Otóż możemy równie dobrze użyć RETURN w pętli by z niej wyjść, ale słowo kluczowe RETURN mówi nam coś innego, zwróć. A co my zwracamy wychodząc z pętli? No nic, także te słowo jest mylne.

Wracając do pętli, może się dziwnie wydawać że nie wiadomo kiedy się ona skończy, gdyż nie jest podoba do żadnej z pętli znanych nam z języka php, ani to for, ani do … while, ani while itd. No właśnie, gdybyśmy nie mieli żadnego warunku w pętli kończącego ją, to dostalibyśmy pętlę nieskończoną. Dlatego taka pętla musi posiadać w sobie warunek skończenia. Musimy na własną rękę inkrementować (itp..) jakaś wartość i sprawdzać ją w pętli. Otóż samej pętli LOOP to uwierzcie mi lub nie, to rzadko będziecie używać. No jest sama w sobie mało przydatna.

Iteracja tablicy elementów

Definicja pętli:

[ <<label>> ]
FOR name IN [ REVERSE ] expression .. expression [ BY expression ] LOOP
    statements
END LOOP [ label ];

Tu jest moc, ukłony dla dev z postgre za wskaźniki. Dzięki językowi proceduralnemu PL/pgSQL, nie musimy się troszczyć o deklaracje wskaźników w pętli i ich wykorzystywanie, są one automatycznie definiowane i używane przez silnik bazy. Dobre co? W postgresie mamy typy tablicowe. Deklaracja jest bardzo podobna jak w innych językach:

• INT[]
• VARCHAR[]

I tak dalej, dobra dajmy na to że mamy funkcję której jednym z argumentów jest właśnie np VARCHAR[], co lepsze możemy zdefiniować argument funkcji jako ANYARRAY, i dzięki temu, możemy do takiej funkcji przesyłać tablicę różnego typu, bez potrzeby martwienia się o to, w jaki sposób to przesyłamy, i tak później przy wrzucaniu danych do bazy musimy rzutować typ. Wracając do sedna, to mamy taką tablice, która składa się np z 6 elementów. Indeksy tablic w postgresql są numerowane od 1 Też sobie wymyślili, no ale dobra. Mamy taką tablice, i dajmy na to że składa się z 240 wierszy. Czyli jest 240 indeksów. Albo i nie, ponieważ taka tablica może być dynamiczna i w sumie nie wiemy jak wielka jest ta tablica, wiemy jedynie że będzie posiadać 6 elementów jeden wiersz. I jak to zrobić? Patrzcie:

FOR i IN ARRAY_LOWER( "_someVar", 1 ) .. ARRAY_UPPER( "_someVar", 1 )
  LOOP
 
    INSERT INTO
      "someTable"
    (
      ... -- jakieś tam kolumny
    )
    VALUES
    (
      "_someVar"[ i ][ 1 ]::INT,
      "_someVar"[ i ][ 2 ]::VARCHAR,
      "_someVar"[ i ][ 3 ]::BOOLEAN,
      "_someVar"[ i ][ 4 ]::BIT,
      "_someVar"[ i ][ 5 ]::NUMERIC,
      "_someVar"[ i ][ 6 ]::BYTEA,
    );
 
  END LOOP;

Co to jest i ? i jest numerem indeksu, nie musimy go definiować w bloku DECLARE, jest on w biegu definiowany.

Jest moc co? Możemy w tablicy przechowywać różnego typu wartości i później w zależności jakiego typu jest dana kolumna, rzutujemy ją do odpowiedniego typu i jazda.

Napisałem powyżej że pętla musi posiadać w sobie warunek skończenia, no właśnie nie musi Tzn w zależności w jakim kontekście jej użyjemy.

Iteracja wyników zapytania

Definicja pętli:

[ <<label>> ]
FOR target IN query LOOP
    statements
END LOOP [ label ];

Nie opisałem definicji tych dwóch pętli, gdyż na przykładzie pierwszej, analiza dwóch pozostałych w przykładach powinna być dość prosta.

Dość fajna i ciekawa pętla, która dość często się przydaje, o co chodzi? Mamy sytuacje że na podstawie jednego wiersza i argumentów w nim zawartych musimy zmienić inne wiersze. Przeliczyć jakieś wartości czy cokolwiek innego.

FOR "__row" IN
  SELECT
    "someColumn"
  FROM
    "someTable"
  WHERE
    "someOtherColumn" = "someVar" -- nie ma tutaj średnika, ważne!
LOOP
  PERFORM "someFunction"( "__row"."someColumn" );
END LOOP;

A teraz trochę co się tam dzieje i co jest czym. Od początku. Zmienna „__row” jest zdefiniowana jako RECORD w bloku DECLARE. Dzięki takiej definicji możemy wykorzystać ją jako obiekt wiersza w pętli, i obiektowo odwoływać się do kolumn pobranych w zapytaniu poprzez właśnie tą zmienną. Tak jak to widzimy w argumencie funkcji „someFunction”. Normalnie pobieramy sobie dane w select, podajemy warunki, sortujemy, robimy zwykłego selecta. Następnie iterujemy elementy wyniku zapytania, wiersz po wierszu. W moim przykładzie wywołujemy w pętli inną funkcję która coś robi. Równie dobrze na podstawie tych elementów z wyniku zapytania możemy robić inne rzeczy jak np aktualizacja innych wierszy w bazie itd.

W sumie, to by było na tyle jeżeli chodzi o pętle, są inne sposoby tworzenia pętli, ale nigdy mi one nie były potrzebne, nigdy z nich nie korzystałem. Także zachęcam do manuala. Jak zwykle w linkach poniżej.

Słów kilka o wydajności

Jeszcze chciałbym o jednej rzeczy wspomnieć, ponieważ dużo osób upiera się przy stwierdzeniu że założenie przeniesienia logiki aplikacji do sql wcale nie odciąży serwera, po prostu przeniesie środek ciężkości w inne miejsce. Ja się z tym stwierdzeniem nie będę kłócił bo to prawda, i jest jeszcze jedna rzecz która mi nie daje spokoju. Niektórzy z Was twierdzą że funkcje plpgsql będą za bardzo obciążać serwer, pewnie że będą jak się je beznadziejnie napisze.

Bardzo prosty przykład, zwykły warunek (koniunkcja), mamy jakieś dane, i potrafimy stwierdzić że w większości przypadków warunek będzie nieprawdziwy, więc po co w takim razie stawiać ten warunek, który będzie nieprawdziwy na drugim miejscu w koniunkcji? Co innego w alternatywie. Taka prosta rzecz, może szału nie zrobi na prędkości uzyskanej na takiej rzeczy, ale należy o tym pamiętać. Druga rzecz, ilość pamięci wykorzystanej przez funkcje, otóż wiadomą rzeczą jest to że gdy zdefiniujemy masę zmiennych, funkcja napęcznieje, a takie zmienne jak: „__isSelected” czy podobnego typu rzeczy można zastąpić w bardzo prosty sposób. Prosty przykład:

PERFORM
  1
FROM
  "someTable"
WHERE
  "someColumn" = "_someVar";
 
IF NOT FOUND THEN
  .... -- coś robimy gdy nie znaleziono
 
ELSE
  ... -- robimy coś innego
 
END IF;

I teraz kolejny przykład przypadku, gdy będziemy wiedzieć że dany warunek w większości przypadków zostanie spełniono to zastąpimy NOT FOUND, po prostu FOUND, nie ustawiamy żadnych zmiennych, nie nadajemy im wartości, a metoda PERFORM jest o tyle fajna, że nie musimy nigdzie przypisywać wartości zwracanych z tego innego SELCT‘a.

To by było na tyle tego całego wpisu, mam nadzieje że był interesujący.

Sortowanie w ltree

Rozwiązanie było bliżej niż można było się tego spodziewać. Miałem z trylion pomysłów jak to rozkminić. Pomyślałem o liczbie rzeczywistej której każda kolejna część po przecinku będzie przedstawiała nr zagłębienia, tylko to nie jest tak łatwo oprogramować i mogłyby wyjść niezłe kaszany, także odpuściłem sobie to. I olśniło mnie ARRAY! No jacha! To przecież jest tak proste i oczywiste że nie wiem o czym my rozmawiamy. Sam sobie ten problem urodziłem, a powodem tego było iż nikt wcześniej nie pisał o tym, w necie to nawet nie ma słowa o tym module, parę rzeczy znajdziemy w manualu i stronie twórców. Ale nikt nie pokwapił się z implementacją tego z sortowaniem i się nie podzielił.

Implementacja ltree z sortowaniem

Otóż sprawa jest banalnie prosta (teraz już jest):

CREATE TABLE "category" (
   "idCategory"  SERIAL PRIMARY KEY NOT NULL,
   "categoryPath"   LTREE,
   "ordering" INT[]
);

I mógłbym powiedzieć amen. Alę dodam jeszcze:

INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top', '{1}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Science', '{1,1}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Science.Astronomy', '{1,1,1}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Science.Astronomy.Astrophysics', '{1,1,1,1}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Science.Astronomy.Cosmology'. '{1,1,1,2}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Science.Astronomy.Planets'. '{1,1,1,3}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Hobbies', '{1,2}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Hobbies.Amateurs_Astronomy', '{1,2,1}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Hobbies.Swiming', '{1,2,2}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Hobbies.Football', '{1,2,3}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Hobbies.Chess', '{1,2,4}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Hobbies.Basketball', '{1,2,5}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Hobbies.Voleyball', '{1,2,6}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Hobbies.Checkers', '{1,2,7}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Hobbies.Cards', '{1,2,8}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Hobbies.Skis', '{1,2,9}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Hobbies.Post_Cards', '{1,2,10}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Hobbies.Book', '{1,2,11}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Collections', '{1,3}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Collections.Pictures', '{1,3,1}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Collections.Pictures.Astronomy', '{1,3,1,1}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Collections.Pictures.Astronomy.Stars', '{1,3,1,1,1}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Collections.Pictures.Astronomy.Galaxies', '{1,3,1,1,2}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Collections.Pictures.Astronomy.Astronauts', '{1,3,1,1,3}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Collections.Pictures.Astronomy.Planets', '{1,3,1,1,4}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Collections.Pictures.Astronomy.Sun', '{1,3,1,1,5}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Collections.Pictures.Astronomy.Earth', '{1,3,1,1,6}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Collections.Pictures.Astronomy.Asteroids', '{1,3,1,1,7}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Collections.Pictures.Astronomy.UFO', '{1,3,1,1,8}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Collections.Pictures.Astronomy.Milk_Way', '{1,3,1,1,9}');
INSERT INTO category ( "categoryPath", ordering ) VALUES ('Top.Collections.Pictures.Astronomy.Space_Ships', '{1,3,1,1,10}');

To powyżej to demo do tabeli, o zapomniałbym o indeksach:

CREATE INDEX "categoryPath_gist_idx" ON "category" USING gist( "categoryPath" );
CREATE INDEX "categoryPath_idx" ON "category" USING btree( "categoryPath" );
CREATE INDEX "ordering_gist_idx" ON "category" USING gist( "categoryPath" );
CREATE INDEX "ordering_idx" ON "category" USING btree( "categoryPath" );

I sobie protestujcie sami jak to świetnie działa. W następnym i przy okazji ostatnim wpisie o ltree, przedstawię wszystkie metody do zarządzania drzewem, oraz widoki.

Instrukcje warunkowe

Ten dział będzie poświęcony po prostu warunkom. Otóż jak wyżej wspomniałem w postgresie możemy stosować różnego rodzaju warunki, począwszy od IFów poprzez CASE skończywszy na COALESCE lub nie.
Popatrzmy na przykład użycia IFa w funkcji:

CREATE..... RETURNS VOID AS $BODY$
  BEGIN
    SELECT
      ....
    FROM
      ...
    WHERE ....;
 
    IF NOT FOUND THEN
      -- coś tu robimy jak nie znaleziono
    ELSE
      -- w innym wypadku co innego lub kończymy RETURNem
    END IF;
  END;
$BODY$ LANGUAGE 'plpgsql';

Jak widać składnia IFa jest trochę podobna do tej której znamy z innych języków z tym że tutaj mamy słowo kluczowe THEN, które nie w każdym języku jest (bodajże w pascalu było ale mi się szukać nie chce). Kończywszy IFa musimy użyć składni END IF; Jak widać nie mamy tutaj żadnych klamer, dlatego ważne jest by stosować wcięcia przy kodowaniu by się samemu nie pogubić w zagłębieniach kodu. Taki kod od razu staje się czytelniejszy.

Jak widać dzięki takim rozwiązaniom ograniczymy się do wywołania tylko jednej funkcji z kodu php, dzięki temu i kod staje się czytelniejszy, w ten sposób można przerzucić pewną cześć logiki aplikacji na bazę danych, co w znacznym stopniu ułatwia pracę (ale i też może utrudnić, o tym później). Nie chce też znowu wałkować manuala, dlatego link do instrukcji warunkowych znajdziecie na dole, ale co jest ważne, konstrukcja musi zwrócić wartość BOOLEAN, ale to jest chyba oczywiste. W postgresie nie mamy znaku porównania tak jak w innych językach, a chodzi mi o podwójny znak równa się ==, tutaj jest tylko pojedynczy znak równa się. No i teraz, kiedy rozróżnić oba te znaki? Otóż bardzo prosto, porównanie jest tylko i wyłącznie w konstrukcjach warunkowych, użycie znaku równa się w postaci:

"_someVar" = "someVar2";

Jest niczym innym jak przypisaniem, i tak samo jak w każdym innym języku programowania jest l-value i r-value, ale o tym już kiedyś wspominałem, także nie będę tego przytaczał ponownie. Jest także inna konstrukcja która pozwoli nam przypisywać wartość zmiennej. Może ktoś z Was kojarzy język „Prolog”? Jak nie to nie ważne, ale w nim jest użyty taki przełącznik warunkowy „:-” a w postgresie mamy „:=” jako alias do „=” z tym że jest to tylko i wyłącznie przypisanie wartości do zmiennej. Także zachęcam Was do używania takiej oto konstrukcji przypisywania:

"_someVar" := "someVar2";

Jest ona czytelna, i oczywista, z niczym innym się kojarzyć nie może jak z przypisaniem.

Wracając do konstrukcji warunkowych to pozostało nam do opisania jeszcze CASE, jest to po prostu cudowna rzecz, coś wspaniałego, gdyż używanie IFów w SELECTcie jest po prostu mało czytelne i niewygodne. Dlatego dostaliśmy CASE, taki postgresowy switch. Do rzeczy, składnia CASE jest dwojaka:

CASE WHEN condition THEN result
     [WHEN ...]
     [ELSE result]
END

albo:

CASE expression
    WHEN value THEN result
    [WHEN ...]
    [ELSE result]
END

W zależności od potrzeb, używamy jednej z nich, ale mała podpowiedź kiedy którą wybrać, otóż gdy mamy warunek na danej kolumnie to lepiej wybrać wariant drugi, podając tą kolumnę jako expression, gdy mamy parę warunków na różnych kolumnach łatwiej jest wtedy operować nimi na pierwszym przykładzie, przykłady w manualau, a ja dwa słowa o wyniku z THEN, otóż podana fraza w THEN zostanie bezwzględnie dorzucona do wyniku zapytania, czyli dzięki temu w THEN możemy podać np nazwę kolumny jaką byśmy chcieli pobrać w zależności o warunku, który zostanie spełniony. nie sprawdzałem ale pewnie też z tego poziomu można by wywołać funkcję. Warto spróbować kiedyś.

To by było tyle na temat CASE i IF, oprócz tego mamy jeszcze takie funkcje jak NULLIF, COALESCE, GREATEST i LEAST. Krótko o tych funkcjach:

COALESCE: Konstrukcja COALESCE(value [, ...]). Zwraca pierwszy argument który nie jest NULLem.
NULLIF: Konstrukcja NULLIF(value1, value2). Zwraca NULL gdy value1 jest równe value2.
GREATEST: Konstrukcja GREATEST(value [, ...]). Zwraca największą wartość z listy argumentów.
LEAST: Konstrukcja jak powyżej, tylko działa na odwrót.

Pętle

Do zobaczenia w przyszłym wpisie pętelki moje kochane.

Wprowadzenie do PL/pgSQL

Krótki i w miarę logicznie opisanym słowem wstępu jest artykuł na wiki o PL/pgSQL, link poniżej. Lecz ja chciałbym to omówić po swojemu, tak by każdy z Was to zrozumiał i przekonał się nad wielkością tego języka, zaczynajmy.
Tak jak nam mówi manual składnia funkcji jest następująca:

CREATE FUNCTION "nazwaFunkcji"( argumenty [, ... ] ) RETURNS [typZwracanegoObiektu] AS $BODY$
  DECLARE -- blok nie obowiązkowy
    -- Możemy w tym bloku definiować zmienne, w "locie" zmiennych definiować nie możemy 
  BEGIN
    -- ciało funkcji
 
    RETURN [zwracanyObiekt] -- klauzula prawie nie obowiązkowa, o tym poniżej
  END;
$BODY$ LANGUAGE 'plpgsql';

Tak mniej więcej przedstawia się schemat konstrukcji funkcji w PL/pgSQL, Pominąłem kwestię bloków w bloku, w sensie że w bloku BEGIN … END możemy zdefiniować kolejny blok kodu. Nigdy mi to nie było jeszcze potrzebne, i wątpię by Wam było, to jest pewnego rodzaju przerost formy nad treścią. Jak widać stosuje tutaj podwójne dolary w sensie $BODY$, można się zapytać dlaczego? Otóż nie musicie stosować podwójnych dolarów zamiast nich możecie zrobić po prostu AS ‘ — i tutaj reszta kodu. Tylko nie wiem czy stać Was na nerwy stracone przy escepowaniu znaków. Otóż przy podwójnych dolarach możemy zachować taką konstrukcję:

SELECT * FROM users WHERE f_name='foobar';

Natomiast przy konstrucji z apostrofem:

SELECT * FROM users WHERE f_name=''foobar'';

Tam nie ma cudzysłowu przy foobar tylko podwójny apostrof. Także używajcie sobie czego chcecie, do woli. A i jeszcze jedno, to co sobie wstawicie pomiędzy podwójne dolarki nie ma znaczenia, ja wyniosłem z pracy nawyk wstawiania tam nazwy funkcji, co mi się osobiście trochę mało podoba, no ale nawyk pozostał. Przedstawiona przeze mnie powyżej konstrukcja nie jest oczywiście odzwierciedleniem tej z manuala, gdyż jest mało jasna, i rzadko się używa np CREATE OR REPLACE gdy co chwilę zmieniamy typy zmiennych przesyłanych w liście argumentów.

Argumenty funkcji PL/pgSQL

Lista argumentów może być podawana dwojako, a nawet trzyjako. Pierwszym z sposobów podawania argumentów do funkcji jest:

CREAT.... "nazwaFunkcji" ( INT, NUMERIC, TEXT, VARCHAR ) .... $BODY$
  DECLARE
    "_nazwaZmiennejInt" ALIAS FOR $1;
    "_nazwaZmiennejNumeric" ALIAS FOR $2;
    "_nazwaZmiennejText" ALIAS FOR $3;
    "_nazwaZmiennejVarchar" ALIAS FOR $4;
  BEGIN
   ....

drugi sposób:

CREAT.... "nazwaFunkcji" ( "_nazwaZmiennejInt" INT, "_nazwaZmiennejNumeric" NUMERIC,  "_nazwaZmiennejText" TEXT, "_nazwaZmiennejVarchar" VARCHAR ) .... $BODY$

trzeci sposób:

CREAT.... "nazwaFunkcji" ( "_nazwaZmiennejInt" INT, OUT "_nazwZwracanejZmiennej" INT, OUT "_nazwaZwracanejZmiennej2" INT ) .... $BODY$

Dzięki tej trzeciej metodzie możemy zwracać więcej niż jeden argument. Możemy też definiować typy zmiennych i też je zwracać o tym zraz.

Zwracane typy

Tak jak wyżej napisałem funkcje PostgreSQL mogą zwracać typy danych które też sami zdefiniujemy, metody mogą zwracać zarówno typ VOID, jeżeli nie potrzebujemy niczego zwrócić to po prostu ustawiamy RETURNS VOID i dzięki takiej konstrukcji klauzula RETURN w ciele kodu jest niewymagana, proste nie?
PostgreSQL to nie PHP, źle mu prześlesz typ danych zdefiniowany jako INT a prześlesz jako ’1′ i będzie to string, w PHP to przejdzie ale w postgre nie. Więc tutaj musimy się pilnować jeżeli chodzi o przesyłanie zmiennych. To samo tyczy się wszystkich typów oraz tych zwracanych, jeżeli w końcowej wersji uzyskamy inny typ niż ten który zdefiniowaliśmy to dostaniemy błędem po oczach próbując przypisać np NUMERIC do INT i w sumie funkcja się nie wykona, nic nie zwróci a weź to debuguj :>

Przykłady

A teraz prosty przykładzik:

CREATE TABLE "foo" ( "id" SERIAL, "bar" TEXT );
 
CREATE FUNCTION "fooBar"( "_bar" TEXT ) RETURNS VOID AS $$
  BEGIN
    INSERT INTO
      "foo"
    (
      "bar"
    )
    VALUES
    (
      "_bar"
    );
  END;
$$ LANGUAGE 'plpgsql';

I teraz przykład użycia:

SELECT "fooBar"( 'Terefere' );

Wykonanie takiego zapytania odpali nam naszą funkcję i wykonana kod w ciele metody.

Parę słów na zakończenie

To był pierwszy wpis z cyklu poświęconego językowi PL/pgSQL, temat jest szeroki jak rzeka i głęboki jak morze. Nie da się wszystkie na raz opisać, nie da się wszystkiego przedstawić i omówić szczegółowo. Następne wpisy będą dotyczyły instrukcji warunkowych oraz pętli. Wszystko możecie oczywiście znaleźć pod linkiem w stopce. Zapomniałbym wszystko co tutaj jest opisywane jest testowane pod najnowszą ver. oznaczoną numerkiem 8.4. Gdy wyjdzie nowsza i w repo będzie siedzieć to poinformuje o zmianie.

CREATE [ OR REPLACE ] [ TEMP | TEMPORARY ] VIEW name [ ( column_name [, ...] ) ]
    AS query

Sama składnia może się wydawać prosta choć nie musi ;] składnia podana w nawiasach kwadratowych jest opcjonalna. Prze zemnie rzadko wykorzystywana, bo nie tworzę jakiś tymczasowych widoków, nie zapisuję widoku do innego schematu niż ten w którym się znajduję ani też nie używam OR REPLACE gdyż jak instaluje na nowo to drop db i amba.

Teraz może co do samej składni

OR REPLACE – co dziwnego o tym piszą w manualu, to się można dowiedzieć na stronie podanej poniżej. Ale przytoczę fragment.

CREATE OR REPLACE VIEW is similar, but if a view of the same name already exists, it is replaced. The new query must generate the same columns that were generated by the existing view query (that is, the same column names in the same order and with the same data types), but it may add additional columns to the end of the list. The calculations giving rise to the output columns may be completely different.

I teraz pytanie, po czorta w takim razie OR REPLACE jeżeli zmienimy sobie całkowicie widok a pozostawimy tą samą nazwę, trochę dziwna akcja, chociaż może nas to też z jednej strony zabezpieczać przed nałogowym wstawianiu OR REPLACE i nie daj Bóg strzelimy gdzieś dwa takie same nazwy widoków, hmmm w sumie może i dobrze.

Przykład jakiegoś widoku? Proszę bardzo, z naszego RBAC’a z zapytania sprawdzającego uprawnienia, zróbmy sobie teraz widok:

CREATE VIEW "checkRightView" AS
SELECT 
  "allow",
  "u2g"."idUser",
  "m"."moduleName",
  "a"."actionName"
FROM 
  "rbac_privilages" p 
LEFT JOIN 
  "rbac_module" m 
ON 
  ( p."idModule" = m."idModule" ) 
LEFT JOIN 
  "rbac_action" a 
ON 
  ( p."idAction" = a."idAction" ) 
LEFT JOIN 
  "rbac_user_to_group" u2g 
ON 
  ( p."idGroup" = u2g."idGroup" );

Dodaliśmy tylko nagłówek create view i ucięliśmy klauzule where, a teraz przykład jak takiego widoku użyć:

SELECT 
  "cRV"."allow"
FROM 
  "checkRightView" AS "cRV"  -- prawie jak honda ^^
WHERE 
  "cRV"."idUser" = 2 
AND 
  "cRV"."moduleName" = 'music' 
AND 
  "cRV"."actionName" = 'index';

Tadam, proste prawda? Tworzenie widoków można by porównać do polimorfizmu, lecz nim nie jest. Co nam to daje? Na pewno przejrzyste zapytania sql, co do debugowania to w sql zawsze był z tym problem, dlatego przed utworzeniem widoku pierw lepiej sprawdzić czy zapytanie śmiga.

Co do ograniczeń widoku, wiążą się z tym pewne niedogodności, gdyż jak widać by mieć dostęp do tabel łączonych w zapytaniu, trzeba pobrać ich elementy w samym zapytaniu (w widoku) by mieć do nich dostęp przy wywoływaniu widoku. Cóż jak to uważam za pewne ograniczenia, czy nim jest teoretycznie? Nie mam takiej wiedzy by to stwierdzić.

Mam nadzieję że ta krótka notka pomoże nie którym zgłębić swoją wiedzę.

Struktura SQL Role Based Access Control

Także do dzieła, struktura bazy danych:

BEGIN;
 
DROP TABLE IF EXISTS "rbac_user" CASCADE;
CREATE TABLE "rbac_user"
(
   "idUser" SERIAL PRIMARY KEY,
   "userName" VARCHAR( 255 ) NOT NULL
);
 
DROP TABLE IF EXISTS "rbac_group" CASCADE;
CREATE TABLE "rbac_group"
(
   "idGroup" SERIAL PRIMARY KEY,
   "groupName" VARCHAR( 255 ) UNIQUE NOT NULL
);
 
DROP TABLE IF EXISTS "rbac_user_to_group";
CREATE TABLE "rbac_user_to_group"
(
   "idUser" INT REFERENCES "rbac_user"( "idUser" ) NOT NULL,
   "idGroup" INT REFERENCES "rbac_group"( "idGroup" ) NOT NULL,
   PRIMARY KEY( "idUser", "idGroup" )
);
 
DROP TABLE IF EXISTS "rbac_module" CASCADE;
CREATE TABLE "rbac_module"
(
   "idModule" SERIAL PRIMARY KEY,
   "moduleName" VARCHAR( 255 ) UNIQUE NOT NULL
);
 
DROP TABLE IF EXISTS "rbac_action" CASCADE;
CREATE TABLE "rbac_action"
(
   "idAction" SERIAL PRIMARY KEY,
   "idModule" INT REFERENCES "rbac_module"( "idModule" ) NOT NULL,
   "actionName" VARCHAR( 255 ) NOT NULL,
   "inherited" BOOLEAN DEFAULT FALSE NOT NULL,
   UNIQUE( "actionName", "idModule" )
);
 
DROP TABLE IF EXISTS "rbac_privilages";
CREATE TABLE "rbac_privilages"
(
   "idGroup" INT REFERENCES "rbac_group"( "idGroup" ) NOT NULL,
   "idModule" INT REFERENCES "rbac_module"( "idModule" ) NOT NULL,
   "idAction" INT REFERENCES "rbac_action"( "idAction" ) NOT NULL,
   "allow" BOOLEAN DEFAULT FALSE NOT NULL,
   PRIMARY KEY( "idGroup", "idModule", "idAction" )
);
 
COMMIT;

Użyłem transakcji, w posgresql można W MySQL też, pod warunkiem że typ tabeli to InnoDB. Ale nie teraz o tym rzecz. Co jest co?

rbac_user – tabela przechowująca użytkowników naszego systemu
rbac_group – tabela przechowująca grupy w naszym systemie
rbac_user_to_group – tabela wiążąca użytkowników z grupami, relacja typu many-to-many (wiele do wielu)
rbac_module – tabela przechowująca nazwy naszych modułów, można to rozumieć jako controllery naszej aplikacji
rbac_action – tabela przechowująca nazwy naszych akcji, trzeba to rozumieć jako metody w naszych controllerach, relacja typu many-to-one (wiele do jednego, to samo co jeden do wielu [one-to-many])
rbac_privilages – a to jest tabela wiążąca grupę użytkowników, moduł i akcję.

Demo Role Based Access Control

Teraz jak to ustrojstwo wypełnić danymi? Bardzo proszę:

BEGIN;
 
INSERT INTO "rbac_user" ( "userName" ) VALUES ( 'przemek' ), ( 'maciej' ), ( 'andrzej' ), ( 'grzesiek' );
INSERT INTO "rbac_group" ( "groupName" ) VALUES ( 'admin' ), ( 'user' ), ( 'moderator' );
INSERT INTO "rbac_user_to_group" VALUES ( 1, 1 ), ( 2, 3 ), ( 3, 2 ), ( 4, 2 );
INSERT INTO "rbac_module" ( "moduleName" ) VALUES ( 'news' ), ( 'articles' ), ( 'download' ), ( 'music' );
INSERT INTO "rbac_action" ( "idModule", "actionName", "inherited" ) VALUES
   ( 1, 'index', FALSE ),
   ( 1, 'edit', FALSE ),
   ( 1, 'add', FALSE ),
   ( 1, 'delete', FALSE ),
   ( 1, 'block', FALSE ),
   ( 2, 'index', TRUE ),
   ( 2, 'edit', TRUE ),
   ( 2, 'add', TRUE ),
   ( 2, 'delete', TRUE ),
   ( 2, 'block', TRUE ),
   ( 3, 'index', TRUE ),
   ( 3, 'edit', FALSE ),
   ( 3, 'add', TRUE ),
   ( 3, 'delete', FALSE ),
   ( 3, 'block', FALSE ),
   ( 3, 'download', TRUE ),   
   ( 4, 'index', TRUE ),
   ( 4, 'edit', TRUE ),
   ( 4, 'add', FALSE ),
   ( 4, 'delete', FALSE ),
   ( 4, 'block', FALSE ),
   ( 4, 'download', FALSE ),
   ( 4, 'play', TRUE );
 
INSERT INTO "rbac_privilages" VALUES 
   ( 1, 1, 1, TRUE ),
   ( 1, 1, 2, TRUE ),
   ( 1, 1, 3, TRUE ),
   ( 1, 1, 4, TRUE ),
   ( 1, 1, 5, TRUE ),
   ( 2, 1, 1, TRUE ),
   ( 2, 1, 2, FALSE ),
   ( 2, 1, 3, TRUE ),
   ( 2, 1, 4, FALSE ),
   ( 2, 1, 5, FALSE ),
   ( 3, 1, 1, TRUE ),
   ( 3, 1, 2, TRUE ),
   ( 3, 1, 3, TRUE ),
   ( 3, 1, 4, TRUE ),
   ( 3, 1, 5, FALSE ),
   ( 1, 2, 6, TRUE ),
   ( 1, 2, 7, TRUE ),
   ( 1, 2, 8, TRUE ),
   ( 1, 2, 9, TRUE ),
   ( 1, 2, 10, TRUE ),
   ( 2, 2, 6, TRUE ),
   ( 2, 2, 7, FALSE ),
   ( 2, 2, 8, TRUE ),
   ( 2, 2, 9, FALSE ),
   ( 2, 2, 10, FALSE ),
   ( 3, 2, 6, TRUE ),
   ( 3, 2, 7, TRUE ),
   ( 3, 2, 8, TRUE ),
   ( 3, 2, 9, TRUE ),
   ( 3, 2, 10, FALSE ),
   ( 1, 3, 11, TRUE ),
   ( 1, 3, 12, TRUE ),
   ( 1, 3, 13, TRUE ),
   ( 1, 3, 14, TRUE ),
   ( 1, 3, 15, TRUE ),
   ( 1, 3, 16, TRUE ),
   ( 2, 3, 11, TRUE ),
   ( 2, 3, 12, FALSE ),
   ( 2, 3, 13, TRUE ),
   ( 2, 3, 14, FALSE ),
   ( 2, 3, 15, FALSE ),
   ( 2, 3, 16, TRUE ),
   ( 3, 3, 11, TRUE ),
   ( 3, 3, 12, TRUE ),
   ( 3, 3, 13, TRUE ),
   ( 3, 3, 14, FALSE ),
   ( 3, 3, 15, TRUE ),
   ( 3, 3, 16, TRUE ),
   ( 1, 4, 17, TRUE ),
   ( 1, 4, 18, TRUE ),
   ( 1, 4, 19, TRUE ),
   ( 1, 4, 20, TRUE ),
   ( 1, 4, 21, TRUE ),
   ( 1, 4, 22, TRUE ),
   ( 1, 4, 23, TRUE ),
   ( 2, 4, 17, TRUE ),
   ( 2, 4, 18, FALSE ),
   ( 2, 4, 19, TRUE ),
   ( 2, 4, 20, FALSE ),
   ( 2, 4, 21, FALSE ),
   ( 2, 4, 22, TRUE ),
   ( 2, 4, 23, TRUE ),
   ( 3, 4, 17, TRUE ),
   ( 3, 4, 18, TRUE ),
   ( 3, 4, 19, TRUE ),
   ( 3, 4, 20, FALSE ),
   ( 3, 4, 21, TRUE ),
   ( 3, 4, 22, TRUE ),
   ( 3, 4, 23, TRUE );
 
COMMIT;

Znowu transakcję, jakoś tak szybciej działa to Jak pewnie zdążyliście zauważyć tabela rbac_action posiada kolumnę „inherited” która w późniejszym etapie mojej implementacji tego paradygmatu będzie potrzebna do tego by w hierarchii definiować czy dana akcja ma być dziedziczona dla pod grup. Taki ficzer.

Teraz tak, żeby to działało co jest wyżej przedstawione na gotowca, czyli copy-paste wymagana jest baza danych postgresql > 8.2. Dlaczego? A otóż dlatego że:

DROP "tabela" IF EXISTS;

jest zaimplementowane od tej versji. Oj brakowało tego brakowało… Nie wiem jak z wierszami podawanymi po przecinku, gdyż w 8.1 to nie działa (mowa tutaj o klauzuli INSERT).

Sprawdzanie uprawnień

Pozostało nam już tylko jak to pobrać, dla przykładu nie tworzyłem żadnych testów wydajnościowych, chodź przyznam że łączymy parę tabel ale utworzone indeksy są w pełni wykorzystywane, przykład jak sprawdzić uprawnienia:

SELECT 
  "allow" 
FROM 
  "rbac_privilages" p 
LEFT JOIN 
  "rbac_module" m 
ON 
  ( p."idModule" = m."idModule" ) 
LEFT JOIN 
  "rbac_action" a 
ON 
  ( p."idAction" = a."idAction" ) 
LEFT JOIN 
  "rbac_user_to_group" u2g 
ON 
  ( p."idGroup" = u2g."idGroup" ) 
WHERE 
  u2g."idUser" = 2 
AND 
  m."moduleName" = 'music' 
AND 
  a."actionName" = 'index';

Możemy sobie z tego ładny widoczek utworzyć, ale może o tym kiedy indziej. A teraz co wykazało explain?

 Nested Loop  (cost=8.28..14.17 rows=1 width=1)
   ->  Nested Loop  (cost=8.28..13.19 rows=1 width=5)
         JOIN Filter: (p."idModule" = m."idModule")
         ->  Hash JOIN  (cost=8.28..10.26 rows=3 width=9)
               Hash Cond: (p."idAction" = a."idAction")
               ->  Seq Scan ON rbac_privilages p  (cost=0.00..1.69 rows=69 width=13)
               ->  Hash  (cost=8.27..8.27 rows=1 width=4)
                     ->  INDEX Scan USING "rbac_action_actionName_key" ON rbac_action a  (cost=0.00..8.27 rows=1 width=4)
                           INDEX Cond: (("actionName")::text = 'index'::text)
         ->  INDEX Scan USING "rbac_module_moduleName_key" ON rbac_module m  (cost=0.00..0.97 rows=1 width=4)
               INDEX Cond: ((m."moduleName")::text = 'music'::text)
   ->  INDEX Scan USING rbac_user_to_group_pkey ON rbac_user_to_group u2g  (cost=0.00..0.97 rows=1 width=4)
         INDEX Cond: ((u2g."idUser" = 2) AND (u2g."idGroup" = p."idGroup"))
(13 rows)

A co explain z analyze?

 Nested Loop  (cost=8.28..14.17 rows=1 width=1) (actual time=0.449..0.480 rows=1 loops=1)
   ->  Nested Loop  (cost=8.28..13.19 rows=1 width=5) (actual time=0.355..0.449 rows=3 loops=1)
         JOIN Filter: (p."idModule" = m."idModule")
         ->  Hash JOIN  (cost=8.28..10.26 rows=3 width=9) (actual time=0.083..0.288 rows=12 loops=1)
               Hash Cond: (p."idAction" = a."idAction")
               ->  Seq Scan ON rbac_privilages p  (cost=0.00..1.69 rows=69 width=13) (actual time=0.012..0.099 rows=69 loops=1)
               ->  Hash  (cost=8.27..8.27 rows=1 width=4) (actual time=0.049..0.049 rows=4 loops=1)
                     ->  INDEX Scan USING "rbac_action_actionName_key" ON rbac_action a  (cost=0.00..8.27 rows=1 width=4) (actual time=0.027..0.036 rows=4 loops=1)
                           INDEX Cond: (("actionName")::text = 'index'::text)
         ->  INDEX Scan USING "rbac_module_moduleName_key" ON rbac_module m  (cost=0.00..0.97 rows=1 width=4) (actual time=0.006..0.008 rows=1 loops=12)
               INDEX Cond: ((m."moduleName")::text = 'music'::text)
   ->  INDEX Scan USING rbac_user_to_group_pkey ON rbac_user_to_group u2g  (cost=0.00..0.97 rows=1 width=4) (actual time=0.005..0.006 rows=0 loops=3)
         INDEX Cond: ((u2g."idUser" = 2) AND (u2g."idGroup" = p."idGroup"))
 Total runtime: 0.576 ms
(14 rows)

I skąd te 14 wierszy? Bladego pojęcia nie mam. (Edit już wiem ;p) Także czekam na Wasze konstruktywne opinie, chce zaznaczyć że całość nie jest tylko moim pomysłem ale również kolegi z pracy Maćka.

Trochę historii
W 2002 roku, dwóch programistów: Teodor Sigaev oraz Oleg Bartunov, wypuściło na światło dzienne moduł ltree (kiedy zaczęli, brak danych). Podeszli do tego dość ogólnego problemu z wielkim dystansem, za to teraz mamy potężne narzędzie całkowicie za darmo. Następne wydania miały na celu wyeliminowanie błędów zgłoszonych przez użytkowników oraz rozszerzyć możliwości o nowe możliwości w indeksie GIST. Więcej na temat samych wydań jak zwykle w paczce do pobrania z ich strony na dole.

Z czym to się je?
Ltree jak już wyżej wspomniałem jest modułem do PosgreSQL’a mający za zadanie przechowywanie danych w sposób przedstawiający strukturę drzewiastą. Implementacja jak najbardziej wydajna. A więc zacznijmy.

W zależności od dystrybucji z jakiej korzystamy, możemy mieć lub nie dodatkową paczkę dla postgresql’a która powinna się nazywać mniej więcej tak: postgresql-contrib

Po zainstalowaniu tych dodatków mamy masę innych rzeczy, z których nie koniecznie będziemy korzystać. Ale nas interesuje ltree, ścieżka ltree.sql u mnie to:

/usr/share/postgresql/8.4/contrib/

a żeby wyszukać gdzie my to mamy:

locate ltree.sql

po wcześniejszym updatedb.

powinniśmy mieć tam plik ltree.sql, musimy ten plik wrzucić do naszej bazy danych. No to jedziemy:

psql nazwaDB < /usr/share/postgresql/8.4/contrib/ltree.sql

powinniśmy mieć wszystko ładnie wrzucone do bazy danych. Teraz zostało nam już tylko utworzenie tabeli i ogień.

Przykładowa tabela z naszym drzewem.

CREATE TABLE "tree" (
   "id"  SERIAL NOT NULL,
   "path"   LTREE,
   "sort" SMALLINT
);

mamy tutaj tabelę którą nazywamy tree, i teraz nowy typ danych LTREE. Nie ma co tu dużo tłumaczyć zaraz sami zobaczycie jak to działa.

Pozostało nam jeszcze założyć indeksy na kolumny:

CREATE INDEX path_gist_idx ON "tree" USING gist(path);
CREATE INDEX path_idx ON "tree" USING btree(path);

oraz możemy sobie w prosty sposób komentarze na kolumny powrzucać:

COMMENT ON COLUMN "tree"."path" IS 'Scieżka drzewa';

Żeby zobaczyć komentarz w psql należy wykonać polecenie:

\d+ "nazwaTabeli"

A teraz dane przykładowe do drzewa:

INSERT INTO "tree" ( "path", "sort" ) VALUES ('Top', 1);
INSERT INTO "tree" ( "path", "sort" ) VALUES ('Top.Science', 1);
INSERT INTO "tree" ( "path", "sort" ) VALUES ('Top.Science.Astronomy', 1);
INSERT INTO "tree" ( "path", "sort" ) VALUES ('Top.Science.Astronomy.Astrophysics', 1);
INSERT INTO "tree" ( "path", "sort" ) VALUES ('Top.Science.Astronomy.Cosmology', 2);
INSERT INTO "tree" ( "path", "sort" ) VALUES ('Top.Hobbies', 2);
INSERT INTO "tree" ( "path", "sort" ) VALUES ('Top.Hobbies.Amateurs_Astronomy', 2);
INSERT INTO "tree" ( "path", "sort" ) VALUES ('Top.Collections', 3);
INSERT INTO "tree" ( "path", "sort" ) VALUES ('Top.Collections.Pictures', 1);
INSERT INTO "tree" ( "path", "sort" ) VALUES ('Top.Collections.Pictures.Astronomy', 1);
INSERT INTO "tree" ( "path", "sort" ) VALUES ('Top.Collections.Pictures.Astronomy.Stars', 1);
INSERT INTO "tree" ( "path", "sort" ) VALUES ('Top.Collections.Pictures.Astronomy.Galaxies', 2);
INSERT INTO "tree" ( "path", "sort" ) VALUES ('Top.Collections.Pictures.Astronomy.Astronauts', 3);

Jak zauważyliście, dane w ścieżce drzewa nie mogą posiadać wolnej przestrzeni, więc należy ją zamienić na np „_”, co nie jest żadnym problemem.

Ścieżka rysuje się mniej więcej tak:



Pobierzmy sobie teraz całe drzewko:

ltree=> SELECT * FROM tree;
 id |                     path                      | sort
----+-----------------------------------------------+------
  1 | Top                                           |    1
  2 | Top.Science                                   |    1
  3 | Top.Science.Astronomy                         |    1
  4 | Top.Science.Astronomy.Astrophysics            |    1
  5 | Top.Science.Astronomy.Cosmology               |    2
  6 | Top.Hobbies                                   |    2
  7 | Top.Hobbies.Amateurs_Astronomy                |    2
  8 | Top.Collections                               |    3
  9 | Top.Collections.Pictures                      |    1
 10 | Top.Collections.Pictures.Astronomy            |    1
 11 | Top.Collections.Pictures.Astronomy.Stars      |    1
 12 | Top.Collections.Pictures.Astronomy.Galaxies   |    2
 13 | Top.Collections.Pictures.Astronomy.Astronauts |    3
(13 rows)

I wszystko wygląda fajnie co? Ale tu się zaczynają schody z którymi ja sam nie potrafiłem sobie poradzić. I po raz któryś poprosiłem depesz’a o pomoc. Sprawa ma się tak: Jak pobrać drzewo z posortowanymi gałęziami względem głębokości? No i tutaj był mój pies pogrzebany. Ale z pomocą przyszedł depesz, ale do sedna sprawy. Dodajmy sobie z 3 rekordy do naszej tabeli:

 INSERT INTO tree (path,sort) VALUES ('Top.Science.Programing',2);
 INSERT INTO tree (path,sort) VALUES ('Top.Science.Chemia',3);
 INSERT INTO tree (path,sort) VALUES ('Top.Science.Fizyka',4);

Teraz nasze drzewko będzie wyglądało tak:

 id |                     path                      | sort
----+-----------------------------------------------+------
  1 | Top                                           |    1
  2 | Top.Science                                   |    1
  3 | Top.Science.Astronomy                         |    1
  4 | Top.Science.Astronomy.Astrophysics            |    1
  5 | Top.Science.Astronomy.Cosmology               |    2
  6 | Top.Hobbies                                   |    2
  7 | Top.Hobbies.Amateurs_Astronomy                |    2
  8 | Top.Collections                               |    3
  9 | Top.Collections.Pictures                      |    1
 10 | Top.Collections.Pictures.Astronomy            |    1
 11 | Top.Collections.Pictures.Astronomy.Stars      |    1
 12 | Top.Collections.Pictures.Astronomy.Galaxies   |    2
 13 | Top.Collections.Pictures.Astronomy.Astronauts |    3
 14 | Top.Science.Programing                        |    2
 15 | Top.Science.Chemia                            |    3
 16 | Top.Science.Fizyka                            |    4
(16 rows)

Co nas w ogóle nie zadowala, próbowałem na różne sposoby:

1 by depesz:

10:12 < depesz> cojack: i think you will need to sort on subltree(path, 0, nlevel(path)-2), sort;

No to jedziemy

ltree=> SELECT * FROM tree ORDER BY subltree(path, 0, nlevel(path)-2), sort;
ERROR:  invalid positions

A dziwne bo wcześniej działało ^^

2 moja

SELECT id, subpath(path, -1) AS title, nlevel(path) AS depth, sort FROM tree ORDER BY subltree(path, 0, nlevel(path)) ASC;
 id |       title        | depth | sort
----+--------------------+-------+------
  1 | Top                |     1 |    1
  8 | Collections        |     2 |    3
  9 | Pictures           |     3 |    1
 10 | Astronomy          |     4 |    1
 13 | Astronauts         |     5 |    3
 12 | Galaxies           |     5 |    2
 11 | Stars              |     5 |    1
  6 | Hobbies            |     2 |    2
  7 | Amateurs_Astronomy |     3 |    2
  2 | Science            |     2 |    1
  3 | Astronomy          |     3 |    1
  4 | Astrophysics       |     4 |    1
  5 | Cosmology          |     4 |    2
 15 | Chemia             |     3 |    3
 16 | Fizyka             |     3 |    4
 14 | Programing         |     3 |    2
(16 rows)

I tutaj można zauważyć że mamy już względnie posortowane według kategorii ale wciąż brak posortowania względem sort po prostu, no i trzecia ostateczna (chyba) propozycja wg depesza podejście drugie:

WITH RECURSIVE rec AS (
SELECT *, btrim(to_char( sort, '0000000' )) AS ordering FROM tree WHERE nlevel(path) = 1
UNION ALL
SELECT t2.*, t1.ordering || '/' || btrim(to_char( t2.sort, '0000000' )) AS ordering FROM rec t1, tree t2 WHERE t1.path @> t2.path AND nlevel(t1.path) + 1 = nlevel(t2.path)
)
SELECT id, subpath(path, -1) AS title, nlevel(path) AS depth, sort FROM rec ORDER BY ordering;
 
 id |       title        | depth | sort
----+--------------------+-------+------
  1 | Top                |     1 |    1
  2 | Science            |     2 |    1
  3 | Astronomy          |     3 |    1
  4 | Astrophysics       |     4 |    1
  5 | Cosmology          |     4 |    2
 14 | Programing         |     3 |    2
 15 | Chemia             |     3 |    3
 16 | Fizyka             |     3 |    4
  6 | Hobbies            |     2 |    2
  7 | Amateurs_Astronomy |     3 |    2
  8 | Collections        |     2 |    3
  9 | Pictures           |     3 |    1
 10 | Astronomy          |     4 |    1
 11 | Stars              |     5 |    1
 12 | Galaxies           |     5 |    2
 13 | Astronauts         |     5 |    3
(16 rows)

Dziękuje nie mam do Pana więcej pytań, rozwalił mnie jego poziom wiedzy.

To co tutaj przedstawiłem to tylko przedsmak tego co dzięki tej sposobności możemy doświadczyć, a są to:

1. ACL
2. RBAC
3. Hierarchia grup
4. Drzewa ^^

Nie będę opisywał funkcji jakie są dostępne w tym module, a na pewno nie w tym wpisie. Chciałem przedstawić że coś takiego istnieje, gdyż bardzo mało osób wie o tym, nie zdaje sobie sprawy z potężnej mocy jaką to posiada.