Poniższy tutorial będzie wprowadzeniem do epizodu tutoriali o języku skryptowym (proceduralnym) PL/pgSQL. Język pl/sql został wymyślony przez Oracle, jego prostota i zarazem potężna siła daje nam wszystko czego potrzeba nam do pracy z postgresql. Język ten pozwala nam na wiele więcej działań niż sam SQL, począwszy od deklaracji zmiennych poprzez pętle skończywszy na triggerach (albo i nie).
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.
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.
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 :>
Pewnego razu gdy medytowałem nad sensem świata, pewna ciekawa rzecz zaprzątnęła moim umysłem. Pytanie co było pierwsze – funkcja czy klasa ? Pytanie, co jest bardziej pierwotnym pojęciem w programowaniu?
Nie ma to może żadnych poważniejszych implikacji dla nas koderów, jednak można dojść do całkiem ciekawych wniosków. Odpowiedzią na pytanie zadane w tytule jest: pierwszy był… void 
.
A tak już całkiem na serio. W matematyce, w algebrze zbiorów najszerszym pojęciem jest klasa, jest ona bytem szerszym od zbioru. Klasa agreguje różne zbiory.
W programowaniu, klasa ma podobne znaczenie, jest czymś co określa pewien rodzaj obiektów. I tu właśnie zaczynają się schody, bo jak wiemy w klasie są metody, czyli funkcje. Więc jak to jest ? Czy może istnieć klasa która składa się z funkcji ? A może, istnieje sobie np. klasa funkcji kwadratowych, czyli wszystkich funkcji w postaci Ax2+bx+c czy klasa funkcji ekspotencjalnych. Co ciekawe np. w języku php da się stworzyć takie klasy:
class SquareFunction { protected $_a = 1; protected $_b = 1; protected $_c = 1; public function __construct($a,$b,$c){ $this->_a = $a; $this->_b = $b; $this->_c = $c; } public function __invoke($x){ return $this->_a*pow($x,2) + $this->_b*$x + $this->_c; } } $func = new SquareFunction(5,6,4); echo $func(10);
Oczywiście jest tu trochę php-owej magii związanej z funkcją __invoke(dostępna od 5.3), dzięki której można wywoływać klasę jako funkcję. Nie mniej jednak logicznie rzecz biorąc jest to podejście słuszne.
Wracając jednak do pytania podstawowego co było pierwsze. Doszedłem do wniosku przemyśliwując sprawę gruntownie, że oba pojęcia są pojęciami pierwotnymi. Nie da się zdefiniować klasy bez funkcji i funkcji bez klasy. Tak jak nie da się podzielić elektronu na pół, ponieważ jest cząstką punktową, a jak wiemy matematyczny punkt jest niepodzielny.
Przypomina mi cała sprawa rzecz wziętą z fizyki, mianowicie dualizm korpuskularno falowy, funkcja jest jednocześnie funkcją i klasą.Z istniejących języków programowania najlepiej oddaje ten dualizm Javascript, gdzie funkcja jednocześnie jest klasą i powiem szczerze, że po tych przemyśleniach okazuje się, że jednak JS ma jakiś głębszy sens
Dziś stała się rzecz, na którą dużo osób czekało. Do trunk-a PHP został commitowany patch umożliwiający typowanie argumentów dla nie obiektów w funkcjach.
Od teraz możliwe jest to:
function foo(int $bar){ return $bar + 5; }
Z tego co pamiętam, typować argumenty można silnie i słabo, tzn: jeżeli w liście argumentów podamy int to wtedy funkcja zaakceptuje tylko argument o typie int. Jeżeli jednak zdeklarujemy to jako (int) to wtedy wszystko co się da rzutować na int-a przejdzie.
Feature zapewne znajdzie się w wersji 5.4 interpretera.
Piekło zamarzło! Wczoraj na blogu Ilia Alshanetsky pojawił się wpis zatytułowany Scalar Type Hints are Here!. Wynika z niego, że do SVN-a dodana została długo oczekiwana funkcjonalność dająca możliwość określenia typu argumentu przekazywanego do funkcji. Oprócz array oraz nazwy klasy, można stosować typy proste jak int, czy string. W praktyce będzie to wyglądać następująco:
Kanał ATOM
function(int $i)
{
// jakieś operacje na zmiennej $i
}
Niestety muszę ostudzić wasz entuzjazm. Modyfikacja ta nie jest jeszcze wprowadzona do oficjalnego wydania języka. Poza tym zanim trafi ona pod nasze strzechy, trochę czasu minie. Nie pamiętam, bym widział hosting z najnowszą wersją PHP.
Z podobnych funkcjonalności brakuje mi jeszcze możliwości określenia typu zwracanego przez funkcję. Może niedługo się pojawi?
