In Postgres è possibile decidere quali informazioni aggiungere al file dei LOG grazie alle numerose opzioni presenti nel file di configurazione del server (postgresql.conf).

Postgres inoltre si integra alla perfezione con demoni di log di sistema come syslog (in ambienti UNIX).

Compito frequente del DBA è leggere i file di log di un server, interpretandoli secondo la propria esperienza.

A volte, specialmente se le informazioni inserite nel log sono tante, i file generati dal server risultano di difficile comprensione se analizzati con strumenti come un semplice editor di testo.

Per facilitare il compito dei DBA sono stati sviluppati strumenti che hanno il compito specifico di analizzare file di log e presentare statistiche utili in un formato facilmente consultabile.

Il più popolare, ad oggi, è sicuramente pgFouine. Vediamo come usarlo e quali alternative vi sono.

pgFouine

URL di riferimento: http://pgfouine.projects.postgresql.org

pgFouine è il più completo analizzatore di log presente ad oggi. Produce report in formato HTML con statistiche generali su query, checkpoint ed errori.

Caratteristiche principali:

• Scritto in PHP (ad oggetti)
• Facilmente estensibile se si ha bisogno di aggiungere report specifici
• Rilasciato con licenza GPL
• Tempo di esecuzione per l’analisi di un log di 52MB: 52.388s

PRO

• Ottimo formato di output
• Statistiche complete sulle query eseguite, sia generali che divise per tipo
• Livello di dettaglio del report selezionabile

CONTRO

• Estrema lentezza ed elevato consumo di memoria

pg_query_analyser

URL di riferimento: https://github.com/WoLpH/pg_query_analyser

pg_query_analyser è un clone C++ di PgFouine. È stato sviluppato da Rick van Hattem, un collega di 2ndQuadrant.

Caratteristiche principali:

• Scritto in C++
• Tempo di esecuzione per l’analisi di un log di 52MB: 4.113s

PRO

• Ottimo formato di output (identico a quello di pgFouine)
• Velocità di esecuzione e consumo ridotto di memoria
• Rilasciato con licenza GPL3

CONTRO

• Raccoglie solo statistiche sulle query (è possibile scegliere il tipo di query da riportare)
• Mancanza di un sistema di templating per personalizzazione dell’output (codice HTML hard-coded nel sorgente C++)

pgbadger

URL di riferimento: https://github.com/dalibo/pgbadger

È l’ennesimo clone di pgFouine. Il suo punto di forza sono sicuramente i grafici, realizzati con una libreria Javascript e di ottima qualità.

Caratteristiche principali

• Scritto in Perl
• Tempo di esecuzione per l’analisi di un log di 52MB: 11.544s

PRO:

• Ottimo formato di output
• Statistiche complete sulle query eseguite, e non solo:
  • Errori
  • Lock
  • File temporanei
  • Sessioni
  • Connessioni
• Modalità watch per riportare solo errori, come avviene nel popolare logwatch (www.logwatch.org)
• Ottima qualità dei grafici
• Rilasciato con licenza BSD

CONTRO

• Nessuno

Conclusioni

Dai test che ho effettuato, pgbadger è risultato essere un ottimo compromesso tra prestazioni nell’analisi e qualità del report.

Se le vostre esigenze sono di analizzare esclusivamente le query, terrei in considerazione pg_query_analyser, che esegue un ottimo lavoro usando un quantitativo di risorse esiguo.

È disponibile il numero #01 di Postgresql Magazine. Per informazioni: http://pgmag.org/01

Il gruppo di utenti PostgreSQL turco (PostgreSQL Turkey User Group) sta organizzando la seconda edizione della conferenza turca su PostgreSQL ad Istanbul, il 12 maggio 2012. Magnus Hagander terrà il discorso di apertura. La registrazione è gratuita. Per informazioni: http://pgday.PostgreSQL.org.tr/2012/

Novità sul prodotto PostgreSQL

ODB 2.0.0,  un ORM per C++, supporta PostgreSQL.

Per informazioni: http://www.codesynthesis.com/pipermail/odb-announcements/2012/000013.html

Per il download: http://www.codesynthesis.com/products/odb/download.xhtml

Offerte di lavoro per PostgreSQL nel mese di maggio

Per informazioni: http://archives.postgresql.org/pgsql-jobs/2012-05/threads.php

Notizie locali su PostgreSQL

PGCon 2012 si terrà nei giorni 17 e 18 maggio 2012 ad Ottawa, Canada, presso l’Università di Ottawa. Sarà preceduto da due giorni di tutorial dal 15 al 16 maggio. Per informazioni: http://www.pgcon.org/2012/

PGDay France si terrà a Lione il 7 giugno 2012. Per informazioni: http://www.pgday.fr

Rassegna stampa su PostgreSQL

Planet PostgreSQL: http://planet.postgresql.org/

Questo notiziario settimanale PostgreSQL è stato realizzato da David Fetter; traduzione parziale in lingua italiana a cura di Carlo Ascani.

Notizie o annunci destinati a questo notiziario dovranno pervenire entro la mezzanotte di domenica (le 15 nel fuso orario della California). I comunicati in lingua italiana dovranno essere inviati a pwn@itpug.org; per le lingue inglese o tedesca, si scriva rispettivamente a david@fetter.org o a pwd@pgug.de. Per lo spagnolo a pwn@arpug.com.ar.

Patch applicate

– Add comments suggesting usage of git_changelog to generate release
notes.
http://git.postgresql.org/pg/commitdiff/f33fe47a9169eec692b80c17ea47bd2f9c261aaf

– Mark git_changelog examples with the proper executable names.
http://git.postgresql.org/pg/commitdiff/7490c48f1e2c51dce77d33f7fd464e72713679a5

– Remove BSD/OS (BSDi) port. There are no known users upgrading to
Postgres 9.2, and perhaps no existing users either.
http://git.postgresql.org/pg/commitdiff/ebcaa5fcde8411786e3765414465174e6d31c8e6

– Fix psql doc typo.
http://git.postgresql.org/pg/commitdiff/768c3affd44d1dcb4e43e2e006c642524714c2a4

– Revert typo fix 768c3affd44d1dcb4e43e2e006c642524714c2a4; I was
wrong.
http://git.postgresql.org/pg/commitdiff/0a3a674b98ebb47e2f4b539a0e284744a7871987

– Document that it is the pgsql version we are matching for psqlrc
version-specific files, not the server version.
http://git.postgresql.org/pg/commitdiff/65b110703b798cdbfa568aa3583caba0ed51b33a

Robert Haas pushed:

– Remove duplicate word in comment. Noted by Peter Geoghegan.
http://git.postgresql.org/pg/commitdiff/0d2235a25bc71848c18f551f992b3eed8cec2399

– Tweak psql to print row counts when \x auto chooses non-expanded
output. Noah Misch
http://git.postgresql.org/pg/commitdiff/9b7a84f2a45322b21b86eb180a869d1ed2937b85

– More duplicate word removal.
http://git.postgresql.org/pg/commitdiff/e01e66f808fbd161b2714eab34bb9e9d0db0db53

– Further corrections from the department of redundancy department.
Thom Brown
http://git.postgresql.org/pg/commitdiff/1b4998fd44bad9f8ab90e741cadd6519f6c94a44

– Avoid repeated CLOG access from heap_hot_search_buffer. At the time
we check whether the tuple is dead to all running transactions,
we’ve already verified that it isn’t visible to our scan, setting
hint bits if appropriate. So there’s no need to recheck CLOG for
the all-dead test we do just a moment later. So, add
HeapTupleIsSurelyDead() to test the appropriate condition under the
assumption that all relevant hit bits are already set. Review by
Tom Lane.
http://git.postgresql.org/pg/commitdiff/003811042139790a5a479c8264271a3248eda36f

– Add missing parenthesis in comment.
http://git.postgresql.org/pg/commitdiff/8e0c5195dff70ffc9c132716d0cf7f3eff45e302

Peter Eisentraut pushed:

– Mark ReThrowError() with attribute noreturn. All related functions
were already so marked.
http://git.postgresql.org/pg/commitdiff/26471a51fc833e2ce58a2f16f891256d57dd28c6

– Improve markup of cmdsynopsis elements. Add more markup in
particular so that the command options appear consistently in
monospace in the HTML output. On the vacuumdb reference page,
remove listing all the possible options in the synopsis. They have
become too many now; we have the detailed options list for that.
http://git.postgresql.org/pg/commitdiff/4266509c577b089627930af39f1dcd2d06b493e9

– Fix display of <command> elements on man pages. We had changed this
from the default bold to monospace for all output formats, but for
man pages, this creates visual inconsistencies, so revert to the
default for man pages.
http://git.postgresql.org/pg/commitdiff/61c84b47619c11e74089cb3160813a4b3c98e6d7

– Remove dead ports. Remove the following ports: dgux, nextstep,
sunos4, svr4, ultrix4, and univel. These are obsolete and not worth
rescuing. In most cases, there is circumstantial evidence that they
wouldn’t work anymore anyway.
http://git.postgresql.org/pg/commitdiff/f2f9439fbfba378cb64cd6e5a046e0184cd542c6

– Even more duplicate word removal, in the spirit of the season
http://git.postgresql.org/pg/commitdiff/e9605a039b60350003daf8a5b3c0c10993994b60

– PL/Python: Fix crash in functions returning SETOF and using SPI.
Allocate PLyResultObject.tupdesc in TopMemoryContext, because its
lifetime is the lifetime of the Python object and it shouldn’t be
freed by some other memory context, such as one controlled by SPI.
We trust that the Python object will clean up its own memory.
Before, this would crash the included regression test case by trying
to use memory that was already freed. reported by Asif Naeem,
analysis by Tom Lane
http://git.postgresql.org/pg/commitdiff/52aa334fcd5a9d230be7e8fb964d94c6c4e63dc7

– doc: Fix for too many brackets in command synopses on man pages.
The default for the choice attribute of the <arg> element is “opt”,
which would normally put the argument inside brackets. But the
DSSSL stylesheets contain a hack that treats <arg> directly inside
<group> specially, so that <group><arg>-x</arg><arg>-y</arg></group>
comes out as [ -x | -y ] rather than [ [-x] | [-y] ], which it would
technically be. But when building man pages, this doesn’t work, and
so the command synopses on the man pages contain lots of extra
brackets. By putting choice=”opt” or choice=”plain” explicitly on
every <arg> and <group> element, we avoid any toolchain dependencies
like that, and it also makes it clearer in the source code what is
meant. In passing, make some small corrections in the documentation
about which arguments are really optional or not.
http://git.postgresql.org/pg/commitdiff/1715ff112809bca5218ddb6eccfda2c20dc420b5

– PL/Python: Improve test coverage. Add test cases for inline handler
of plython2u (when using that language name), and for result object
element assignment. There is now at least one test case for every
top-level functionality, except plpy.Fatal (annoying to use in
regression tests) and result object slice retrieval and slice
assignment (which are somewhat broken).
http://git.postgresql.org/pg/commitdiff/e6c2e8cb87846161033e1f215876c4b95f631df0

Tom Lane pushed:

– Converge all SQL-level statistics timing values to float8
milliseconds. This patch adjusts the core statistics views to match
the decision already taken for pg_stat_statements, that values
representing elapsed time should be represented as float8 and
measured in milliseconds. By using float8, we are no longer tied to
a specific maximum precision of timing data. (Internally, it’s
still microseconds, but we could now change that without needing
changes at the SQL level.) The columns affected are
pg_stat_bgwriter.checkpoint_write_time,
pg_stat_bgwriter.checkpoint_sync_time,
pg_stat_database.blk_read_time, pg_stat_database.blk_write_time,
pg_stat_user_functions.total_time, pg_stat_user_functions.self_time,
pg_stat_xact_user_functions.total_time, and
pg_stat_xact_user_functions.self_time. The first four of these are
new in 9.2, so there is no compatibility issue from changing them.
The others require a release note comment that they are now double
precision (and can show a fractional part) rather than bigint as
before; also their underlying statistics functions now match the
column definitions, instead of returning bigint microseconds.
http://git.postgresql.org/pg/commitdiff/809e7e21af8cd24855f1802524a13bbaa823f929

– Kill some remaining references to SVR4 and univel. Both terms still
appear in a few places, but I thought it best to leave those alone
in context.
http://git.postgresql.org/pg/commitdiff/50c2d6a1a63f04fd8c4553fc696c2c9e235b1a25

– Overdue code review for transaction-level advisory locks patch.
Commit 62c7bd31c8878dd45c9b9b2429ab7a12103f3590 had assorted
problems, most visibly that it broke PREPARE TRANSACTION in the
presence of session-level advisory locks (which should be ignored by
PREPARE), as per a recent complaint from Stephen Rees. More
abstractly, the patch made the LockMethodData.transactional flag not
merely useless but outright dangerous, because in point of fact that
flag no longer tells you anything at all about whether a lock is
held transactionally. This fix therefore removes that flag
altogether. We now rely entirely on the convention already in use
in lock.c that transactional lock holds must be owned by some
ResourceOwner, while session holds are never so owned. Setting the
locallock struct’s owner link to NULL thus denotes a session hold,
and there is no redundant marker for that. PREPARE TRANSACTION now
works again when there are session-level advisory locks, and it is
also able to transfer transactional advisory locks to the prepared
transaction, but for implementation reasons it throws an error if we
hold both types of lock on a single lockable object. Perhaps it
will be worth improving that someday. Assorted other minor cleanup
and documentation editing, as well. Back-patch to 9.1, except that
in the 9.1 branch I did not remove the LockMethodData.transactional
flag for fear of causing an ABI break for any external code that
might be examining those structs.
http://git.postgresql.org/pg/commitdiff/71b9549d053b2f0a9e76e829c917385841f84bee

Heikki Linnakangas pushed:

– Remove duplicate words in comments. Found these with grep -r “for
for “.
http://git.postgresql.org/pg/commitdiff/f291ccd43e06fdd7c55102975a0b2f38bc140b90

Magnus Hagander pushed:

– Remove link to ODBCng project from the docs. This backatches
Heikki’s patch in 140a4fbf1a87891a79a2c61a08416828d39f286a to make
sure the documentation on the website gets updated, since we’re
regularly receiving complains about this link.
http://git.postgresql.org/pg/commitdiff/6d362ec209f0174f36a78936c5269f8d5f2cd26e

Patch rifiutate (per adesso)

Nessuno è stato scontentato questa settimana. :-)

Patch in attesa

of hung connection attempts in libpq.

Noah Misch sent in a patch to prevent a theoretical torn page hazard
in ginRedoUpdateMetapage().

Pavel Stehule sent in a patch to add new error fields to PL/pgsql.

Laurenz Albe sent in another revision of the patch to analyze foreign
tables which gets the FDW to show that a value was non-NULL but
removed due to excess width by returning a value of length
WIDTH_THRESHOLD+1.

Peter Geoghegan sent in two revisions of a patch to latch up the WAL
Writer, reducing wake-ups and thus saving electricity in a way that is
more-or-less analogous to his previous work on the BGWriter.

Magnus Hagander sent in a patch to reduce the number of “Unexpected EOF
on client connection” messages clogging people’s logs.

Jan Urbanski sent in a patch to fix an issue with PL/PythonU where
result set slicing was broken in the Python3 case.

Il primo passo consiste nell’abilitare i backport:

cat << E_O_BACKPORTS > /etc/apt/sources.list.d/backports.list deb http://www.backports.org/debian lenny-backports main contrib non-free deb-src http://www.backports.org/debian lenny-backports main contrib non-free E_O_BACKPORTS

cat << E_O_APTPREF >> /etc/apt/preferences

Package: 2ndquadrant_italia_mod.txt 2ndquadrant_italia.txt da_installare_pandoc hdoisajds.sh risultati step2 Pin: release a=lenny-backports Pin-Priority: 200 E_O_APTPREF

wget -O – http://backports.org/debian/archive.key | apt-key add –

apt-get update

Poi installare postgresql-8.4

apt-get -t lenny-backports postgresql-8.4 postgresql-contrib-8.4 postgresql-doc-8.4

Semplice, no?

La maggior parte delle modifiche presenti in PostgreSQL 8.4 riguardano nuovi strumenti e nuovi comandi dedicati all’amministrazione o al monitoraggio, unitamente a nuove versioni di soluzioni già presenti nella versione 8.3. Ogni utente, indipendentemente dalle proprie caratteristiche preferite, troverà più facile e produttivo il lavoro quotidiano.

"Usiamo PostgreSQL già da sette anni, e stiamo aspettando con trepidazione molte delle novità della versione 8.4, in particolare i permessi sulle colonne, la localizzazione a livello di singolo database, i match parziali per gli indici GIN e le eccezioni definite dall’utente", afferma Jeffrey Webster, CTO di ZooLoo.com. "PostgreSQL ci ha permesso di crescere senza sacrificare l’integrità dei dati."

Tra i miglioramenti più attesi troviamo:

• Restore del database in parallelo, per velocizzare fino ad 8 volte un ripristino da backup
• Permessi per singola colonna, per permettere un controllo più granulare dei dati sensibili
• Supporto alla collation per singolo database, per rendere PostgreSQL più utile in ambienti multilingua
• Aggiornamenti in loco tramite pg_migrator beta, per permettere aggiornamenti dalla 8.3 alla 8.4 senza lunghe interruzioni del servizio
• Nuovi strumenti per il monitoraggio delle interrogazioni, per dare agli amministratori maggiori informazioni sull’attività delle query

La versione 8.4 rende più facile l’analisi dei dati tramite le funzioni avanzate dello standard ANSI SQL2003, quali le funzioni di windowing, le common table expression

e le join ricorsive. "Queste strutture di query aumentano notevolmente l’espressività del dialetto SQL di PostgreSQL, permettendo agli utenti di formulare con una sola query delle domande interessanti che sarebbero state impossibili in precedenza", spiega Sailesh Krishnamurti, fondatore di Truviso. Le migliorie alle stored procedure, come i parametri di default ed i parametri variadici, rendono più semplice e compatta la programmazione del server di database.

La nuova versione migliora le prestazioni delle applicazioni, come commenta Kevin Grittner, amministratore di database per il sistema giudiziario del Wisconsin: "PostgreSQL continua a migliorare le prestazioni ad ogni versione. La versione 8.4 ha aggiunto diverse ottimizzazioni, come le semi-join e le anti-join, le quali permettono una notevole riduzione dei tempi di esecuzione di alcune delle nostre query più intensive."

Queste caratteristiche implicano che PostgreSQL coprirà un numero di utenze maggiore di prima, come ad esempio sta accadendo al progetto OpenStreetMap. "In fase di progettazione della nuova versione delle API di OpenStreetMap, emerse la necessità di affidarsi a un database di classe superiore che, oltre a coprire le funzionalità desiderate, risultasse adeguato alle dimensioni richieste dal progetto. Benché ci fossero molti database open source, la scelta ovvia è stata PostgreSQL.", dice Tom Hughes, amministratore di sistema per OpenStreetMap.

Elenco delle caratteristiche

La versione 8.4 ha un numero senza precedenti di nuove caratteristiche. Al fine di poterle elencare tutte, abbiamo creato delle pagine dedicate:

• Lista completa delle caratteristiche (solo in inglese)
• Matrice delle caratteristiche (solo in inglese)
• Note di rilascio

Guida alle novità (in italiano)

• Le novità del linguaggio SQL
• Le novità per gli amministratori di PostgreSQL
• Le novità per i programmatori di stored procedure
• Le restanti novità

Citando il comunicato stampa ufficiale, PostgreSQL 8.4 "contiene un elevato numero di miglioramenti che rendono più semplice che mai l’amministrazione, l’interrogazione e la programmazione dei database PostgreSQL. Grazie alle 293 tra migliorie e novità della versione 8.4, ci sono ancora più ragioni che suggeriscono di scegliere PostgreSQL per il vostro prossimo progetto".

2ndQuadrant Italia ha predisposto nelle ultime settimane una serie di articoli sulle novità di PostgreSQL:

• Le novità di SQL
• Le novità di amministrazione di PostgreSQL
• Le novità per i programmatori di stored procedure
• Le restanti novità

Dopo avere trattato le novità in materia di SQL, di amministrazione e di stored procedure, cercherò di elencare alcune fra le restanti novità di PostgreSQL 8.4. In particolare:sicurezza, performance e strumenti a disposizione per gli utenti (come psql).

Prestazioni

Come ogni evoluzione precedente, anche Postgres 8.4 è stato oggetto di cambiamenti volti a migliorarne le prestazioni e le performance. Tra le modifiche principali, spiccano:

1. utilizzo di metodi basati hash per interrogazioni di tipo SELECT DISTINCT, UNION/INTERSECT/EXCEPTION (in precedenza, per queste operazioni Postgres era costretto a ordinare i dati e quindi ad eliminarli per ottenere valori distinti);
2. il valore di default del parametro default_statistics_target per il planner è stato aumentato a 100, e il valore massimo da 1000 a 10000 (utile per data warehouse)
3. ottimizzazione del planner per query EXISTS/NOT EXISTS e sub-select;
4. migliorate le prestazioni per operazioni di caricamento di massa (bulk load).

Permessi a livello di colonna

Al fine di proteggere dati sensibili e di garantire un maggiore controllo sull’accesso agli stessi da parte degli utilizzatori di database, gli amministratori sono finalmente in grado di concedere o revocare permessi di lettura, scrittura e aggiornamento su di un singolo campo di una tabella.

Maggiori approfondimenti:

• Il comando GRANT
• Il comando REVOKE

Autenticazione SSL

Gli utenti possono essere ora autenticati utilizzando certificati SSL. Gli amministratori possono definire politiche di accesso basate su specifici certificati SSL. Inoltre, PostgreSQL 8.4 supporta le catene di certificati SSL.

Ripristino in parallelo (parallel restore)

pg_restore supporta la modalità di processing parallelo, permettendo il caricamento dei dati e la creazione degli oggetti all’interno del database in diversi flussi paralleli. A seconda dell’hardware a disposizione e della struttura del database, questa funzionalità permette ridurre la durata del ripristino di file di backup fino a 8 volte rispetto al restore tradizionale su singolo processo. Si noti che il restore parallelo di PostgreSQL 8.4 può essere utilizzato anche per operazioni di ripristino di database su Postgres 8.3 e 8.2.

È possibile abilitare il processing parallelo specificando il numero di job da riga di comando, con l’opzione -j o --jobs.

Documentazione per l’applicazione pg_restore.

Miglioramenti a psql (applicazione client da console)

L’applicazione psql, la più utilizzata dagli amministratori di database PostgreSQL, è stata oggetto di notevoli migliorie. Di seguito è fornita una lista delle principali modifiche:

1. migliorata la gestione delle linee di comando e dei caratteri di tabulazione
2. aggiunte informazioni sul tipo di memorizzazione su disco delle colonne (i.e. plain, extended, ecc.)
3. migliorata la visualizzazione delle sequenze
4. migliorati la gestione e il controllo dell’opzione timing
5. aggiunta la visualizzazione dei valori accettati per i tipi di dato enum
6. aggiunta la visualizzazione della dimensione di una tabella (escluse tabelle collegate e indici), con il comando dt+
7. il comando d NOME_TABELLA permette di visualizzare le chiavi esterne collegate a campi della tabella corrente (molto utile e comodo per vedere i vincoli di integrità referenziale direttamente dalla tabella master)
8. aggiunta la visualizzazione della dimensione del database e dei relativi tablespace, rispettivamente con i comandi l e l+
9. migliorata la funzionalità di auto-completamento per tabelle su schemi multipli
10. rimossi gli oggetti di sistema dalla visualizzazione nei comandi della famiglia d: ad esempio df mostrerà soltanto le funzioni definite dall’utente e non più anche quelle di sistema (finalmente!), visualizzabili con il comando dfS
11. aggiunta la possibilità di editare direttamente da psql le funzioni utilizzando l’editor preferito con il comando ef NOME_FUNZIONE

Finalmente, siamo giunti alla fine di questo speciale. Spero di avere reso giustizia agli sviluppatori di PostgreSQL e alle novità da loro introdotte (circa 300!) in questo anno e mezzo di sviluppo della versione 8.4. E soprattutto spero che questi articoli in italiano possano avvicinare nuovi utenti a PostgreSQL.

A questo punto, non ci resta che aspettare l’uscita di PostgreSQL 8.4, attesa per la fine di giugno. Ciao!

Questo articolo è una traduzione da me riadattata del documento "What’s new in 8.4" del PostgreSQL Global Development Group. Ringrazio inoltre Hubert Lubaczewski per la serie di articoli "Waiting for 8.4".

Funzioni con un numero variabile di parametri ( xml:lang=”en”>variadic parameter)

Le funzioni variadic, ovvero che accettano un numero variabile di parametri, sono adesso parte integrante di PostgreSQL grazie all’introduzione della parola chiave VARIADIC in fase di specifica del parametro di input della procedura/funzione.

Per approfondimenti:

• hreflang=”en”>Le funzioni SQL con un numero variabile di argomenti
• hreflang=”en” xml:lang=”en”>Waiting for 8.4 – variadic functions

Parametri con valori di default

È stata aggiunta la possibilità di aggiungere parametri con valori di default nelle stored procedure, in modo da gestire i casi in cui l’utente di una particolare funzione non fornisca uno o più argomenti alla chiamata. Questa funzionalità rende molto più semplice la manutenzione delle stored procedure e la migrazione delle stesse da applicazioni di database su sistemi come SQL server e Sybase.

Per approfondimenti:

• hreflang=”en”>Le funzioni SQL con valori di default per gli argomenti
• hreflang=”en” xml:lang=”en”>Waiting for 8.4 – Default values for function arguments + integer in any base

Funzioni PL/pgSQL che ritornano una tabella (RETURNS TABLE)

Una scorciatoia conforme allo standard SQL per rendere più leggibile la specifica di funzioni con numerosi parametri in uscita, tramite la parola chiave RETURNS TABLE. La funzionalità è essenzialmente un alias di RETURNS SETOF, ma rende molto più veloce la scrittura di funzioni che si comportano come tabelle e che ritornano insiemi di righe.

Per approfondimenti:

• hreflang=”en”>Le funzioni SQL che ritornano una tabella
• hreflang=”en” xml:lang=”en”>Waiting for 8.4 – RETURNS TABLE

Struttura di controllo CASE in PL/pgSQL

Grazie all’introduzione dell’istruzione di controllo xml:lang=”en”>switch CASE in PL/pgSQL, che permette di eseguire codice basato sul confronto di un valore con una lista di condizione, vedremo progressivamente sparire l’utilizzo di blocchi IF .. ELSIF .. ELSIF .. ELSIF.

Per approfondimenti:

• hreflang=”en”>Le strutture di controllo in PL/pgSQL
• hreflang=”en” xml:lang=”en”>Waiting for 8.4 – CASE in PL/pgSQL

Potenziato il comando RAISE in PL/pgSQL per il lancio di eccezioni

Gli sviluppatori di stored procedure in PL/pgSQL ameranno molto le modifiche fatte da Pavel Stehule alla gestione delle eccezioni. Il comando RAISE è stato potenziato:

1. è in grado di collegare all’eccezione sollevata dall’utente e ai messaggi di errore informazioni di dettaglio (opzione DETAIL) e suggerimenti (opzione HINT)
2. è finalmente in grado di associare un codice di errore SQLSTATE all’eccezione (utilizzando sia codici predefiniti che non)
3. permette di associare nomi alle eccezioni utente
4. è possibile ri-sollevare una eccezione al blocco try esterno tramite il comando RAISE senza parametri ( in gergo tecnico rethrow)

Senza dubbio gli sviluppatori di stored procedure in PL/pgSQL hanno adesso a disposizione un set di funzionalità in grado di dar loro maggior controllo alla gestione delle eccezioni e degli errori.

Per approfondimenti:

• hreflang=”en”>Errori e messaggi in PL/pgSQL
• hreflang=”en” xml:lang=”en”>Waiting for 8.4 – PL/pgSQL RAISE

Supporto per parametri con EXECUTE in PL/pgSQL

La creazione di query dinamiche con EXECUTE è stata semplificata notevolmente con l’introduzione dei parametri di esecuzione, da specificare con la clausola USING. Con questa modifica, non è più necessario creare query dinamiche concatenando stringhe e valori.

Per approfondimenti:

• hreflang=”en”>l’istruzione EXECUTE in PL/pgSQL
• hreflang=”en” xml:lang=”en”>Waiting for 8.4 – PL/pgSQL EXECUTE ... USING

Supporto per RETURN QUERY EXECUTE in PL/pgSQL

È stata aggiunta la possibilità in PL/pgSQL di far ritornare alle funzioni il risultato di query dinamiche, tramite l’istruzione RETURN QUERY EXECUTE.

Per approfondimenti:

• hreflang=”en”>Strutture di controllo in PL/pgSQL
• hreflang=”en” xml:lang=”en”>Waiting for 8.4 – PL/pgSQL RETURN QUERY EXECUTE

Le funzioni che ritornano insiemi di record (SRF) possono essere richiamati all’interno di clausole SELECT

Questa funzionalità, finora utilizzabile soltanto nelle procedure in linguaggio SQL, è stata estesa ai linguaggi procedurali. Adesso è possibile eseguire query del tipo select i, funzione_test(1, i) from generate_series(1,3) i, dove funzione_test è una SRF scritta in un linguaggio procedurale come PL/pgSQL.

Approfondimento: Waiting for 8.4 – pl/* srf functions in selects

Trigger a livello di istruzione da scatenare in seguito a comando TRUNCATE

Ecco una funzionalità molto importante (soprattutto per i sistemi di replica basati su trigger) sviluppata dal nostro Simon Riggs che vede aggiungere la possibilità di specificare trigger a livello di istruzione (statement level trigger) da eseguire in seguito al verificarsi di un evento TRUNCATE su una tabella. Questa aggiunta è da considerarsi a tutti gli effetti una estensione di PostgreSQL, non contemplata dallo standard SQL.

Per approfondimenti (in inglese):

• Il comando CREATE TRIGGER
• Il comando TRUNCATE
• Panoramica sul comportamento dei trigger

Questo articolo è una traduzione da me riadattata del documento “What’s new in 8.4” del PostgreSQL Global Development Group. Ringrazio inoltre Hubert Lubaczewski per la serie di articoli “Waiting for 8.4“.

Ecco una lista delle principali novità in ambito "amministrazione" di PostgreSQL 8.4.

Collation a livello di database

Il tipo dell’ordine alfabetico delle stringhe di caratteri è da adesso una proprietà dei database invece che una proprietà del server definita a livello di inizializzazione. Questo permette agli utenti di avere molteplici linguaggi naturali (lingue) pienamente supportati dalla stessa installazione di PostgreSQL.

Questa funzionalità spiana la strada alle collation a livello di tabella e di colonna, presumibilmente già dalle prossime release di PostgreSQL.

Approfondimento sul comando CREATE DATABASE.

Mappa di visibilità (Visibility Map)

Grazie ad un registro in memoria che tiene traccia delle pagine "sporcate" dalle transazioni (la cosiddetta "mappa di visibilità"), il processo di VACUUM riesce a leggere solamente le pagine che necessitano di pulizia invece di scandire tutte le pagine della tabella. La mappa di visibilità permette pertanto di ridurre notevolmente i tempi di vacuum per tabelle di grandi dimensioni.

Approfondimento su "Visibility Map".

Mappa di spazio libero ottimizzata in modo automatico (free space map)

Una modifica molto importante al backend di PostgreSQL 8.4 è la gestione automatica della mappa di spazio libero (free space map). Fino alla versione 8.3 compresa, gli amministratori dovevano impostare il parametro max_fsm_pages per stabilire il numero di pagine su disco delle quali tenere traccia nella mappa di spazio libero all’interno della memoria condivisa. Questo parametro richiedeva un attento studio da parte degli amministratori del server di PostgreSQL.

Ebbene, con PostgreSQL 8.4, l’opzione max_fsm_pages è definitivamente sparita: il sistema è in grado di tenere traccia in modo automatico e con molta più precisione lo spazio libero all’interno di ogni pagina. Ad ogni tabella infatti viene affiancata una mappa di spazio libero memorizzata su disco.

Configurazione di auto-vacuum a livello di tabella con i comandi CREATE TABLE e ALTER TABLE / SET

Rispetto a PostgreSQL 8.3, non è più necessario inserire manualmente nel catalogo pg_autovacuum le configurazioni a livello di tabella per auto-vacuum. Adesso è possibile gestire la configurazione a livello di tabella con i comandi CREATE TABLE e ALTER TABLE. Inoltre (e finalmente), la configurazione di auto-vacuum è adesso salvata da pg_dump.

Per maggiori informazioni:

• il comando CREATE TABLE
• il comando ALTER TABLE

Esecuzione a tempo per pgbench

E’ possibile richiedere a pgbench "quante cose riesce a fare in uno specifico lasso di tempo", piuttosto che "quanto tempo impiega a eseguire uno specifico set di operazioni". La differenza è soprattutto nell’organizzazione dei test e nell’analisi dei risultati: paragonare il numero di query eseguito in un intervallo di tempo è molto più semplice ed efficace.

La funzione pg_conf_load_time()

Non dovrai più indovinare se il file postgresql.conf è più nuovo di quello utilizzato dal server PostgreSQL in azione: è possibile confrontare la sua data di modifica con quella del risultato della funzione pg_conf_load_time().

Visualizzazione fino a livello di colonna per EXPLAIN verbose

Adesso il comando EXPLAIN VERBOSE fornisce informazioni utili sulle colonne che ogni nodo dell’albero delle query restituisce al padre: questo tipo di informazioni mostra quanto pessima sia "SELECT *".

Riporta tutte le query coinvolte in un errore di deadlock

Informazioni sui deadlock sono fornite direttamente dal server PostgreSQL, senza necessità di scoprirle dai log.

Migliorate informazioni di pg_settings

pg_settings è in grado di mostrare le opzioni disponibili per le istruzioni globali di configurazione utente (GUC) con un insieme definito di valori. Molte impostazioni infatti accettano valori enumerati, e pg_settings è adesso in grado di mostrarli, facilitando la vita all’utente.

Migliorata la gestione dei certificati SSL

Le connessioni SSL possono adesso prevenire da attacchi del tipo man-in-the-middle, grazie alla verifica dei certificati del client.

Indici GIN multi-colonna

E’ possibile adesso avere indici GIN multi-colonna.

Approfondimento su indici GIN.

Miglioramenti al file pg_hba.conf

Adesso è possibile specificare opzioni di autenticazione nella forma NOME=VALORE. E’ stata inoltre rimossa l’opzione ident sameuser, rendendola di default nel caso in cui la usermap non sia specificata.

Per maggiori informazioni e per gli altri cambiamenti, si rimanda alla sezione della documentazione sul file pg_hba.conf.

Questo articolo è una traduzione da me riadattata del documento "What’s new in 8.4" del PostgreSQL Global Development Group. Ringrazio inoltre Hubert Lubaczewski per la serie di articoli "Waiting for 8.4".

Ecco una lista delle principali novità in ambito SQL di PostgreSQL 8.4.

Funzioni finestra (Windowing Functions)

Anche conosciute con il termine "windowing aggregate", le funzioni finestra permettono di effettuare operazioni di aggregazione (come count(), sum(), ecc.) e di rango come (rank() e row_number()) su un sottoinsieme dei dati (la cosiddetta finestra o window).

A livello pratico, questo comporta che report multi-livello che in precedenza avrebbero richiesto 3 o 4 query (e possibilmente la scrittura di procedure), possano essere ora generati con una singola query.

Le funzioni finestra ampliano il numero di applicazioni di Business Intelligence e supporto alle decisioni che PostgreSQL è in grado di supportare.

Approfondimento su Window Function e sulla sintassi delle chiamate.

Common Table Expression (CTE) e query ricorsive

Le Common Table Expression, anche conosciute con il nome di query WITH, permettono la creazione di subquery e di assegnar loro un nome. Le subquery possono a loro volta essere referenziate all’interno delle clausole della query alla quale appartengono.

Oltre a rimuovere la necessità di creare tabelle temporanee per alcune operazioni, le Common Table Expression consentono di eseguire query ricorsive nelle quali poter attraversare strutture ad albero o grafi all’interno di una singola query, in modo efficiente. Ciò risulta particolarmente importante per tutte le applicazioni che hanno dati organizzati in strutture gerarchiche come forum, gestori di file e organigrammi.

Approfondimento su Common Table Expression

Comando TABLE

Come specificato dallo standard SQL, il comando TABLE nome_tabella esegue la stessa identica mansione del comando SELECT 2ndquadrant_italia_mod.txt 2ndquadrant_italia.txt da_installare_pandoc hdoisajds.sh risultati step2 FROM nome_tabella.

Il comando SELECT

ALTER SEQUENCE RESTART e TRUNCATE TABLE RESTART IDENTITY

Tramite le istruzioni ALTER SEQUENCE RESTART e TRUNCATE TABLE RESTART IDENTITY è adesso possibile azzerare in modo semplice le sequenze, ripristinando il valore iniziale. La prima agisce sull’oggetto sequenza, la seconda azzera la sequenze associate alle colonne della tabella che si intende svuotare.

Per approfondimenti:

• Il comando ALTER SEQUENCE

• Il comando TRUNCATE

Aggiunta di una colonna con ALTER VIEW

Permette di aggiungere colonne alla fine di una vista esistente, senza dover ricostruire le dipendenze della vista. Modifiche o rimozioni di colonne continuano a richiedere la ricostruzione delle dipendenze.

LIMIT (espressione o subquery)

Adesso è possibile limitare il numero di righe restituite da una interrogazione al database utilizzando una espressione oppure addirittura una subquery. In precedenza, LIMIT vincolava all’utilizzo di una costante numerica. Questa modifica rende più facile per una singola vista o stored procedure ad esempio di supportare in modo dinamico meccanismi di paginazione.

Esempio per il recupero del primo 10% dei record della tabella notizie: SELECT 2ndquadrant_italia_mod.txt 2ndquadrant_italia.txt da_installare_pandoc hdoisajds.sh risultati step2 FROM notizie ORDER BY orario DESC LIMIT (SELECT count(*) / 10 FROM notizie);

Approfondimento su clausola LIMIT

Parola chiave AS opzionale per alias di colonna

Questa funzionalità, che renderà il passaggio da MySQL a PostgreSQL meno doloroso, rende opzionale la specifica della parola chiave "AS" nell’assegnazione di alias di colonna all’interno delle query.

Esempio: SELECT tablename tabella FROM pg_tables;

Il comando SELECT

Migliorata la conformità rispetto alla standard SQL per la gestione degli intervalli temporali

La specifica degli intervalli temporali è stata potenziata e resa più conforme rispetto allo standard SQL. E’ stato inoltre aggiunto il supporto per la specifica di intervalli secondo lo standard ISO 8601.

Esempio di specifica di intervallo secondo lo standard ISO 8601: SELECT INTERVAL 'P2Y1M1DT4H20M7.5S';

Tipi di dato per date e orari

Questo articolo è una traduzione da me riadattata del documento "What’s new in 8.4" del PostgreSQL Global Development Group. Ringrazio inoltre Hubert Lubaczewski per la serie di articoli "Waiting for 8.4".

Il cosiddetto feature freeze (ovvero l’interruzione nell’aggiunta di nuove funzionalità al codice) di PostgreSQL 8.4 è avvenuto il primo novembre 2008. Da quel momento, lo sviluppo di PostgreSQL è coinciso con la revisione delle patch inviate, e l’applicazione di quelle considerate valide e funzionanti. Il 15 aprile, la prima beta release di PostgreSQL 8.4 è stata messa a disposizione per il test diffuso da parte degli utenti di tutto il mondo. Se sei su questa pagina, ti starai chiedendo di sicuro: "cosa posso fare per aiutare il progetto PostgreSQL?".

Ecco una lista di attività da fare per partecipare al programma beta:

1. effettuare un backup dell’attuale sistema di database utilizzando sia la versione corrente che quella nuova di pg_dump, e caricarle nel database 8.4
2. in un ambiente di test, provare tutte le applicazioni che si interfacciano con il database in produzione con il database aggiornato alla 8.4
3. qualora riscontrassi dei problemi o degli errori, sei pregato di informare il team di sviluppo riempiendo il modulo di invio bug – in inglese
4. se la tua piattaforma non è elencata nel servizio di creazione automatica dei binari di PostgreSQL (Automatic Build Farm), sei pregato di scaricare i sorgenti e di verificare che tu sia in grado di compilare PostgreSQL. Sei benvenuto nel dare riscontri positivi o negativi sulla mailing list pgsql-hackers@postgresql.org
5. leggi attentamente la documentazione di PostgreSQL 8.4 in fase di sviluppo, in modo speciale per quanto riguarda le nuove funzionalità; ogni suggerimento è bene accetto

Sei infine incoraggiato a iscriverti alla mailing list pgsql-hackers, qualora ancora tu non lo abbia fatto. In questa mailing list avviene la maggior parte dello sviluppo di PostgreSQL, e gli utenti che partecipano al programma beta dovrebbero iscriversi per ricevere informazioni aggiornatissime sul processo di sviluppo.

Di seguito trovi alcuni link utili:

• Area FTP con il codice sorgente di PostgreSQL 8.4 beta
• Area FTP con binari di tipo MSI Installer per Windows
• One-Click installer per Windows e Mac
• Repository YUM con pacchetti RPM per varie distribuzioni Linux
• Lista di elementi aperti (Open Item) per PostgreSQL 8.4
• Note di Rilascio di PostgreSQL 8.4