Documentazione di PostgreSQL 9.0 > Programmazione del server > Linguaggi procedurali
PrecedenteRules versus TriggersPL/pgSQL - Linguaggio procedurale SQLSuccessivo

38. Linguaggi procedurali

PostgreSQL™ permette che le funzioni definite dall'utente siano scritte in altri linguaggi oltre a SQL e C. Questi altri linguaggi sono chiamati genericalmente linguaggi procedurali (PL). Per una funzione scritta in un linguaggio procedurale, il server database non ha conoscienze incluse riguardo a come interpretare il sorgenete della funzione. Invece, il compito viene passato a un gestore speciale che conosce i dettagli del linguaggio. Il gestore potrebbe fare sia tutto il lavoro di parsing, analisi di sintassi, esecuzione, ecc. da solo, sia fungere da «collante» tra PostgreSQL™ e un'implementazione esistente di un linguaggio di programmazione. Il gestore stesso è una funzione C compilata all'interno di un oggetto condiviso e caricato su richiesta, esattamente come qualsiasi altra funzione C.

Attualmente ci sono quattro linguaggi procedurali disponibili nella distribuzione standard di PostgreSQL™: PL/pgSQL (Capitolo 39, PL/pgSQL - Linguaggio procedurale SQL), PL/Tcl (Capitolo 40, PL/Tcl - Tcl Procedural Language), PL/Perl (Capitolo 41, PL/Perl - Perl Procedural Language) e PL/Python (Capitolo 42, PL/Python - linguaggio procedurale python). Ci sono linguaggi procedurali aggiuntivi disponibili che non sono incluse nella distribuzione core. Appendice G, External Projects raccoglie informazioni su come trovarli. In aggiunta possono essere definiti altri linguaggi dall'utente; le basi per lo sviluppo di un nuovo linguaggio procedurale sono trattate in Capitolo 49, Writing A Procedural Language Handler.

38.1. Installare i linguaggi procedurali

Un linguaggio procedurale deve essere «installato» in ogni database dove sarà usato. Ma i linguaggi procedurali installati nel database template1 sono automaticamente disponibili in tutti i database creati successivamente, dato che le loro voci in template1 saranno copiate da CREATE DATABASE. Così l'amministratore può decidere quali linguaggi sono disponibili in quali database e se vuole può rendere alcuni linguaggi disponibili in modo predefinito.

Per i linguaggi forniti con la distribuzione standard, è necessario solamente eseguire CREATE LANGUAGE language_name per installare il linguaggio nel database corrente. Alternitavamente, il programma createlang(1) può essere usato per farlo dalla shell. Per esempio, per installare il linguaggio PL/Perl nel database template1, usare:

createlang plperl template1

La procedura manuale descritta sotto è raccomandata solo per installare linguaggi personalizzati sconosciuti a CREATE LANGUAGE.

Procedura 38.1.  Installazione manuale di un linguaggio procedurale

Un linguaggio procedurale viene installato in un database in cinque passi, che devono essere portati avanti da un superutente del database. (Per linguaggi conosciuti a CREATE LANGUAGE, i passi dal secondo al quarto possono essere omessi, dato che saranno svolti automaticamente se necessario).

  1. L'oggetto condiviso per il gestore del linguaggio deve essere compilato e installato in una directory apposita. Questo funziona nello stesso modo di compilare e installare moduli come fanno normali funzioni C definite dall'utente; si veda Sezione 35.9.6, «Compiling and Linking Dynamically-Loaded Functions». Spesso, il gestore del linguaggio dipenderò da una libreria esterna che fornisce l'effetivo motore del linguaggio di programmazione; se è così, dev'essere installato anche quello.

  2. Il gestore dev'essere dichiarato con il comando

    CREATE FUNCTION handler_function_name()
        RETURNS language_handler
        AS 'path-to-shared-object'
        LANGUAGE C;
    

    Il tipo di ritorno speciale language_handler dice al sistema di database che questa funzione non restituisce un tipo di dato definito in SQL e non è direttamente usabile in istruzioni SQL.

  3. Opzionalmente, il gestore del linguaggio può fornire una funzioni «inline» che esegue blocchi anonimi di codice (comandi DO(7)) scritti in questo linguaggio. Se una funzione handler inline viene fornita dal linguaggio, dichiararla con un comando come

    CREATE FUNCTION inline_function_name(internal)
        RETURNS void
        AS 'path-to-shared-object'
        LANGUAGE C;
    

  4. Opzionalmente, il gestore del linguaggio può fornire una funzione «validator» che controlla la correttezza di una funzione senza eseguira realmente. La funzione validator è chiamata da CREATE FUNCTION se esiste. Se una funzione validator viene fornita dal linguaggio, dichiararla con un comando come

    CREATE FUNCTION validator_function_name(oid)
        RETURNS void
        AS 'path-to-shared-object'
        LANGUAGE C;
    

  5. Il PL dev'essere dichiarato con il comando

    CREATE [TRUSTED] [PROCEDURAL] LANGUAGE language-name
        HANDLER handler_function_name
        [INLINE inline_function_name]
        [VALIDATOR validator_function_name] ;
    

    La parola chiave opzionale TRUSTED specifica che il linguaggio non concede accesso ai dati che l'utente non avrebbe altrimenti. I linguaggi trusted sono progettati per utenti normali del database (quelli senza privilegio di superutente) e permettono loro di creare in maniera sicura funzioni e procedure trigger. Dato che le funzioni PL sono eseguite all'interno del server database, il flag TRUSTED dovrebbe essere fornito solo per linguaggi che non permettono l'accesso all'interno del server database o al file system. I linguagggi PL/pgSQL, PL/Tcl, e PL/Perl sono considerati trusted; i linguaggi PL/TclU, PL/PerlU, e PL/PythonU sono progettati per fornire funzionalità illimitate e non dovrebbero essere segnati come trusted.

Esempio 38.1, «Installazione manuale di PL/Perl» mostra come la procedura di installazione manuale dovrebbe funzionare con il linguaggio PL/Perl.

Esempio 38.1. Installazione manuale di PL/Perl

I seguenti comandi dicono al server database dove trovare l'oggetto condiviso per la funzione che gestisce le chiamate del linguaggio PL/Perl:

CREATE FUNCTION plperl_call_handler() RETURNS language_handler AS
    '$libdir/plperl' LANGUAGE C;

PL/Perl ha una funzione di gestione inline e una funzione validator, così si dichiarano anche queste:

CREATE FUNCTION plperl_inline_handler(internal) RETURNS void AS
    '$libdir/plperl' LANGUAGE C;

CREATE FUNCTION plperl_validator(oid) RETURNS void AS
    '$libdir/plperl' LANGUAGE C;

Il comando:

CREATE TRUSTED PROCEDURAL LANGUAGE plperl
    HANDLER plperl_call_handler
    INLINE plperl_inline_handler
    VALIDATOR plperl_validator;

quindi definire che le funzioni dichiarate precedentemente dovrebbero essere invocate per le funzioni e le procedure trigger dove l'attributo linguaggio è plperl.


In una installazione predefinita di PostgreSQL™, il gestore per il linguaggio PL/pgSQL è compilato e installato nella directory «library»; inoltre, il linguaggio PL/pgSQL stesso vine installato in tutti i database. Se il supporto a Tcl è configurato, i gestori per PL/Tcl and PL/TclU sono compilati e installati nella directory library, ma il linguaggio stesso non viene installato in nessun database in maniera predefinita. Ugualmente, i gestori di PL/Perl e PL/PerlU sono compilati e installati se il supporto Perl è configurato, e il gestore PL/PythonU viene installato se il supporto a Python è configurato, ma questi linguaggi non sono installati in modo predefinito.

Documentazione di PostgreSQL 9.0 > Programmazione del server > Linguaggi procedurali
PrecedenteRules versus TriggersPL/pgSQL - Linguaggio procedurale SQLSuccessivo