Gentoo Logo

Guida rapida a PostgreSQL

Indice:

1.  Introduzione

Un po' su PostgreSQL

PostgreSQL è un sistema libero ed open source per la gestione di basi di dati relazionali. Supporta funzionalità quali le transaction, gli schema e le foreign key, ed è spesso considerato più strettamente aderente agli standard SQL e più sicuro, di default, di ogni altro database, commerciale o meno.

Visitare la pagina About su postgresql.org per ulteriori informazioni.

Di cosa questo articolo si occupa

Questo articolo contiene dettagli, specifici per Gentoo, sull'installazione del database PostgreSQL.

Gli ebuild utilizzati in questo articolo sono dev-db/postgresql-docs, dev-db/postgresql-base e dev-db/postgresql-server.

In questo articolo si assume che il lettore voglia installare l'ultima versione stabile di PostgreSQL che, al momento di scrivere, è la 9.0.3. Si prega di modificare i comandi che verranno proposti in modo da utilizzare la versione di proprio gradimento.

Importante: Il supporto per le versioni del ramo 8.2 verrà interrotto nel dicembre 2011. Si consiglia di pianificare per tempo la migrazione a versioni successive.

A proposito degli ebuild

Gli ebuild per PostgreSQL presenti in Portage ricorrono alla funzionalità di slotting sulla base della versione primaria. Questo consente di avere simultaneamente due instanze di PostgreSQL appartenenti a versioni primarie diverse, ad esempio la 8.4 e la 9.0. Ciò è utile nel caso in cui si debbano spostare dati da un vecchio database ad uno nuovo, oppure qualora occorra installare sulla stessa macchina un database sperimentale ed uno in produzione. Inoltre questa funzionalità impedisce che un database venga sovrascritto da un aggiornamento incompatibile, assieme alle librerie e agli eseguibili corrispondenti. Questo infatti richiederebbe una migrazione, che ad ogni modo è descritta in questa guida.

Bug e problemi di sicurezza possono invece essere corretti effettuando semplici aggiornamenti che si contraddistinguono per una variazione della sola versione secondaria, e possono essere applicati senza timore di corrompere un database o l'installazione stessa di PostgreSQL; la versione 9.0.2 può essere facilmente aggiornata alla 9.0.3 in quanto la loro compatibilità è garantita, e ciò richiede soltanto il riavvio del processo; non sono necessarie la migrazione, la riconfigurazione o l'inizializzazione.

Leggere la pagina sulle regole in merito alle versioni di PostgreSQL per maggiori informazioni.

Di cosa questo articolo non si occupa

Molti aspetti non verranno trattati. Basti pensare che la documentazione ufficiale consiste in approssimativamente 2000 pagine, e questa invece è una guida rapida. Ci si occuperà solo di problematiche specifiche derivanti dall'impiego di PostgreSQL in ambiente Gentoo, oltre a qualche raccomandazione per una configurazione di base.

2.  Installazione

Gli ebuild obsoleti

Qualora sul proprio sistema sia ancora presente uno qualunque dei seguenti ebuild è necessario subito effettuare una migrazione: dev-db/postgresql-libs, dev-db/postgresql-client, dev-db/libpq e dev-db/postgresql.

Questo articolo si occupa della migrazione dai vecchi ebuild a quelli nuovi.

USE flag

Flag USE Significato
doc Con questa opzione la documentazione in linea verrà installata sul sistema.
kerberos Abilita il supporto all'impiego di Kerberos per l'autenticazione.
ldap Abilita il supporto per l'utilizzo dell'autenticazione LDAP e per il controllo del parametro di connessione.
nls Abilita la visualizzazione dei messaggi in una lingua diversa dall'inglese. Questa flag viene usata insieme alla variabile LINGUAS di Portage.
pam Abilita il supporto ai Pluggable Authentication Modules per l'autenticazione.
perl Abilita il supporto all'utilizzo di Perl per scrivere funzioni e attivare procedure.
pg-intdatetime (deprecata) Usa il nuovo metodo che si basa su valori interi a 64-bit per la visualizzazione dei timestamp al posto del vecchio metodo che si basa su valori a virgola mobile. A meno di non disporre di un'installazione precedente che utilizza il vecchio metodo, lasciare questa USE flag abilitata (vedere le note).
pg_legacytimestamp Usa il vecchio metodo che si basa su valori a virgola mobile al posto del nuovo metodo che si basa su valori interi a 64-bit. A meno di non disporre di un'installazione precedente che utilizza il vecchio metodo, lasciare questa USE flag disabilitata (vedere le note).
python Abilita il supporto all'utilizzo di Python per scrivere funzioni e attivare procedure.
readline È vivamente consigliato di abilitare questa flag. Se disabilitata verranno infatti rimosse le funzionalità di history e di editing della linea di comando da psql.
selinux Installa le policy SELinux. Questa flag può essere abilitata soltanto usando il profilo SELinux.
ssl Abilita il supporto alle connessioni SSL.
tcl Abilita il supporto all'utilizzo di Tcl per scrivere funzioni e attivare procedure.
threads Rende le librerie del client thread-safe. Il resto del sistema deve anch'esso essere thread-safe.
uuid Include il supporto alla generazione di identificatori casuali unici a 128 bit. Ciò è utile quando occorre unire assieme dei database, in modo tale che la probabilità di avere collisioni risulti estremamente bassa.
xml Abilita il supporto a SQL/XML.
zlib Abilita il supporto ad archivi compressi in pg_dump e pg_restore.

Nota: Se si altera la flag "pg-intdatetime" o la flag "pg_legacytimestamp" è poi necessario effettuare il dump ed il restore di ogni database che utilizza i timestamp. I due metodi sono tra loro incompatibili.

Avviare l'installazione

Codice 2.1: Installare il server PostgreSQL

# emerge -av dev-db/postgresql-server

[ebuild N ] dev-db/postgresql-docs-9.0.3 0 kB
[ebuild N ]dev-db/postgresql-base-9.0.3 USE="doc nls pam readline ssl zlib
-kerberos -ldap -pg_legacytimestamp -threads" LINGUAS="-af -cs -de -es -fa -fr
-hr -hu -it -ko -nb -pl -pt_BR -ro -ru -sk -sl -sv -tr -zh_CN -zh_TW" 0 kB
[ebuild N ] dev-db/postgresql-server-9.0.3 USE="doc nls perl python
-pg_legacytimestamp (-selinux) -tcl -uuid -xml" LINGUAS="-af -cs -de -es -fa
-fr -hr -hu -it -ko -nb -pl -pt_BR -ro -ru -sk -sl -sv -tr -zh_CN -zh_TW" 0 kB

È possibile che uno o più tra i paccheti riportati sopra risulti essere bloccato da uno o più tra i seguenti pacchetti: dev-db/postgresql-libs, dev-db/postgresql-client, dev-db/libpq o dev-db/postgresql. Questi pacchetti non sono più supportati e sono obsoleti. Si prega di consultare la sezione sulla migrazione per sapere come gestire questa situazione.

Preparazione all'inizializzazione del cluster di database

Una volta terminata l'installazione dei pacchetti si può procedere alla modifica del file /etc/conf.d/postgresql-9.0. Ci sono tre righe che non possono essere cambiate in seguito senza dover prima procedere all'eliminazione della directory che contiene il cluster di database e alla reinizializzazione.

PGDATA definisce la posizione dei file di configurazione. DATA_DIR definisce invece il luogo in cui creare il cluster di database e i file ad esso correlati. PG_INITDB_OPTS, infine, può contenere opzioni extra a discrezione dell'utente. Tali opzioni extra, tuttavia, non sono in alcun modo obbligatorie in quanto le opzioni predefinite sono del tutto ragionevoli.

Nel seguente esempio PGDATA dichiara che i file di configurazione sono posti in /etc/postgresql-9.0/. DATA_DIR dichiara invece che il cluster di database è posto in /var/lib/postgresql/9.0/data/ (la directory predefinita). Qualora le scelte del lettore differissero da quelle predefinite si tenga conto che è comunque un'ottima idea mantenere la versione primaria nel percorso. PG_INITDB_OPTS dichiara infine che il locale di default è en_US.UTF-8, e che cioè verranno usati l'ordinamento e la formattazione dell'inglese americano, e la codifica dei caratteri UTF-8.

Codice 2.2: Esempio del contenuto di /etc/conf.d/postgresql-9.0

# Percorso dei file di configurazione.
PGDATA="/etc/postgresql-9.0/"
# Percorso della directory data.
DATA_DIR="/var/lib/postgresql/9.0/data"
# Opzioni extra da passare a initdb.
# Consultare "man initdb" per conoscere le opzioni disponibili.
PG_INITDB_OPTS="--locale=en_US.UTF-8"

Nota: Le impostazioni precedenti determinano solamente il locale e la codifica dei caratteri predefiniti. È possibile specificare locale e codifiche dei caratteri diversi in fase di creazione del database (CREATE DATABASE) all'interno dello stesso cluster di database.

Ci sono sei opzioni che, se usate, hanno la precedenza su --locale=. La seguente tabella elenca le sei opzioni per le quali è necessario usare lo schema --opzione=lo_LO.ENCODING.

Opzione Effetti
lc-collate Ordinamento delle stringhe
lc-ctype Classificazione dei caratteri (Cos'è una lettera? Qual è l'equivalente maiuscolo di una lettera?
lc-messages Lingua dei messaggi
lc-monetary Formattazione delle somme di denaro
lc-numeric Formattazione dei numeri
lc-time Formattazione delle date e degli orari

Se ad esempio l'utente vuole che l'inglese sia la lingua predefinita ma che i messaggi vengano visualizzati in svedese occorre definire PG_INITDB_OPTS nel seguente modo:

Codice 2.3: Esempio

PG_INITDB_OPTS="--locale=en_US.UTF-8 --lc-messages=sv_SE.UTF-8"

Un elenco completo delle lingue e delle codifiche dei caratteri supportate dal server è disponibile nella documentazione, ma anche il sistema deve supportarle. Il lettore può confrontare l'output del comando locale -a con la pagina nella documentazione sulle codifiche .

È possibile cambiare il locale e la codifica dei caratteri al momento della creazione di un database, mentre per farlo successivamente è necessario effettuare il drop del database e iniziare da capo.

Codice 2.4: Completare l'installazione

# emerge --config dev-db/postgresql-server:9.0

Questo comando crea il cluster di database e memorizza tutti i file corrispondenti in PGDATA e DATA_DIR.

3.  Configurazione

Posizione dei file di configurazione

Questa volta l'attenzione sarà focalizzata sui file che si trovano nella directory definita da PGDATA, /etc/postgresql-9.0, ed in particolare sui file postgresql.conf e pg_hba.conf.

postgresql.conf

Questo è il file di configurazione principale. Di immediato interesse è la riga con listen_addresses. Questa variabile definisce infatti gli indirizzi ai quali PostgreSQL effettua il binding. Normalmente esso è effettuato solo con localhost e con i socket Unix. Cambiare listen_addresses non è sufficiente se si vogliono abilitare le connessioni remote. Questo argomento verrà affrontato nella prossima sezione. La documentazione ufficiale è abbastanza semplice da comprendere ed è piuttosto esauriente. Si consiglia di leggere anche quella in aggiunta a ciò che è scritto qui in quanto alcune cose possono differire.

Di secondaria importanza è il percorso per i file di log. Normalmente tutto viene memorizzato in postmaster.log nella directory DATA_DIR. Esiste un'intera sottosezione in postgresql.conf con numerose opzioni per come, dove e di cosa effettuare il log. Questa sottosezione è indicata con: ERROR REPORTING AND LOGGING.

A parte listen_addresses e le opzioni per il logging, le altre impostazioni predefinite sono piuttosto ragionevoli, e consentono al lettore di procedere oltre.

pg_hba.conf

Il file di configurazione pg_hba.conf serve ad indicare coloro i quali possiedono l'autorizzazione a connettersi al server e quale metodo di autenticazione deve essere usato per stabilire tale connessione. Ancora una volta la documentazione è piuttosto esauriente nel spiegare il significato di ciascuna opzione, ma alcune cose sono trattate qui al fine di chiarire alcuni punti.

Codice 3.1: pg_hba.conf predefinito

# TYPE DATABASE USER CIDR-ADDRESS METHOD
# "local" è solo per connessioni tramite gli Unix domain socket
local all all trust
# connessioni IPv4 locali:
host all all 127.0.0.1/32 trust
# connessioni IPv6 locali:
host all all ::1/128 trust

Come si accennava in precedenza, il server è abbastanza sicuro anche nelle sue impostazioni predefinite. L'unico database di cui si effettua il log è postgres. Inoltre l'unico modo per stabilire una connessione al database è tramite il socket Unix /var/run/postgresql/.s.PGSQL.5432, che appartiene all'utente e al gruppo di sistema postgres, oppure tramite localhost. Ad ogni modo ogni utente del sistema può stabilire una connessione con il database tramite localhost, anche come utente amministratore del database postgres.

Tuttavia per stabilire una connessione tramite il socket Unix gli utenti, compresi quelli di altri servizi come apache, devono appartenere al gruppo di sistema postgres. Il lettore può usare il comando gpasswd -a utente postgres per aggiungere utente al gruppo postgres. Agli utenti che non appartengono al gruppo postgres viene negato l'accesso con il messaggio "Permission denied".

Avvertenza: Si prega di non disabilitare mai completamente il socket Unix in quanto gli script init richiedono di poter accedere ad esso per il loro corretto funzionamento. La modalità invece può essere cambiata liberamente.

Il metodo trust è quello che permette ad ogni utente del sistema di effettuare l'accesso come un qualunque utente del database senza fornire la password. In altre parole questo metodo specifica che occorre consentire ogni connessione verso un determinato database ad ogni utente del database stesso (ma non da ogni utente di sistema) senza fornire una password, a patto comunque che la provenienza e il tipo della connessione siano quelli previsti. Ciò non è così pericoloso come può apparire in prima battuta, ma costituisce comunque un serio rischio per la sicurezza nelle circostanze più comuni.

I due metodi che vengono generalmente utilizzati sono password e md5. Il metodo password specifica che una password è necessaria per stabilire una connessione e che essa viene trasmessa in chiaro. Questo metodo è appropriato quando tali informazioni non lasciano la macchina da cui provengono, ad esempio nel caso in cui ci si connette tramite il socket unix o localhost. Il metodo md5 è simile al precedente, ma protegge la password adoperando un hash md5. È questo il metodo preferito qualora la password debba attraversare una rete.

A questo punto è possibile concentrarsi sulle ultime due righe (quattro se si includono i commenti) del file pg_hba.conf. PostgreSQL supporta nativamente il protocollo IPv6 indipendentemente dalle esigenze dell'utente. Inoltre agli indirizzi IPv4 sono automaticamente associati indirizzi IPv6. Ad esempio a 127.0.0.1 viene associato ::FFFF:127.0.0.1 e l'indirizzo "puro" ::FFFF:7F00:0001.

Sembra comunque esserci un'incomprensione quanto alle modalità con le quali ai nomi di host vengono associati gli indirizzi IP. Il file di riferimento è /etc/hosts.

Codice 3.2: Esempio di /etc/hosts

# Alias IPv4 e IPv6 per localhost
127.0.0.1 localhost
::1 localhost

Dall'esempio precedente è possibile notare che ad entrambi gli indirizzi IPv4 e IPv6 viene associato localhost. Quando consulta questo file psql prende la prima corrispondenza e usa quella come indirizzo, in questo caso 127.0.0.1. Quando analizza il file PostgreSQL usa anche il corrispondende indirizzo IPv6, ovvero ::ffff:127.0.0.1. Se invece l'indirizzo IPv6 appare prima, allora psql usa soltanto ::1, e ::1 non equivale a ::ffff:127.0.0.1. In questo caso infatti se a ::1 non corrisponde un valido metodo di accesso, psql non sarà in grado di stabilire una connessione. Inoltre il kernel deve supportare il protocollo IPv6.

È quindi meglio specificare soltanto gli indirizzi IP per psql in pg_hba.conf piuttosto che dipendere da un corretto ordinamento interno al file /etc/hosts, dal momento che ciò elimina ogni possibile dubbio in merito a quali indirizzi IP siano ammessi o a quale server ci si connette.

4.  Avviare il server

Fare un tentativo

Occorre ora avviare PostgreSQL e impostare la password per l'utente postgres. I seguenti comandi vanno impartiti dall'utente root:

Codice 4.1: Avviare il server

(Impostare "password" invece che "trust" per le connessioni a
localhost.)
# nano -w /etc/postgresql-9.0/pg_hba.conf
# /etc/init.d/postgresql-9.0 start
postgresql-9.0 | * Starting PostgreSQL ... [ ok ]

(Stabilire una connessione con il server e impostare la password.)

# psql -U postgres
psql (9.0.3)
Type "help" for help.
postgres=# \password
Enter new password:
Enter it again:
postgres=# \q

(Impostare "password" invece che "trust" per la connessione locale.)

# nano -w /etc/postgresql-9.0/pg_hba.conf
# /etc/init.d/postgresql-9.0 reload
postgresql-9.0 | * Reloading PostgreSQL configuration ... [ ok ]
# rc-update add postgresql-9.0 default
* service postgresql-9.0 added to runlevel default

A questo punto si può proseguire con il tutorial ufficiale di PostgreSQL, che guida il lettore nella creazione dei role, dei database e degli schema.

5.  Migrazione

Casi in cui occorre effettuare una migrazione

Ci sono solo due casi in cui occorre effettuare una migrazione: quando si passa da una versione principale ad un'altra, ad esempio dalla versione 8.4.7 di PostgreSQL alla versione 9.0.3 (ma non dalla 9.0.2 alla 9.0.3); o quando si passa dal vecchio formato a virgola mobile per i timestamp a quello nuovo basato su numeri interi a 64-bit.

Nota: Occorre effettuare la migrazione del database anche quando si smette di usare i vecchi ebuild (dev-db/libpq, dev-db/postgresql, dev-db/postgresql-libs e dev-db/postgresql-client) per passare a quelli nuovi (dev-db/postgresql-docs, dev-db/postgresql-base e dev-db/postgresql-server).

Migrazione per versioni a partire dalla 9.0

pg_upgrade è un nuovo strumento, disponibile a partire dalla versione 9.0, che semplifica molto il processo di migrazione.

Ci sono però due fattori che bisogna considerare quando si usa pg_upgrade. Il primo è che pg_upgrade non supporta il caso in cui i file di configurazione siano in una directory differente da quella in cui si trovano i dati. Questo problema può essere risolto usando i collegamenti simbolici. Il secondo è che pg_upgrade può essere usato solo per effettuare la migrazione di database creati con una versione di PostgreSQL pari o superiore alla 8.3. Se si dispone di database più vecchi è necessario leggere le istruzioni specifiche per versioni precedenti alla 9.0.

Codice 5.1: Effettuare la migrazione con pg_upgrade

(Fermare i server dai quali e verso i quali si effettua la migrazione.)

# /etc/init.d/postgresql-8.4 stop
# /etc/init.d/postgresql-9.0 stop
# ln -s /etc/postgresql-8.4/*.conf /var/lib/postgresql/8.4/data/
# ln -s /etc/postgresql-9.0/*.conf /var/lib/postgresql/9.0/data/
(Controllare le versioni disponibili, e poi selezionare le proprie.)

# eselect postgresql list
# eselect postgresql set 9.0

(Impostare su "trust" il metodo dell'utente "postgres" sulle
connessioni locali per ogni database.)
# nano -w /etc/postgresql-8.4/pg_hba.conf
# nano -w /etc/postgresql-9.0/pg_hba.conf

(Potrebbe essere necessario cambiare i permessi della directory
"/var/lib/postgresql/" prima di procedere con il passo successivo.)
# su - postgres
$ pg_upgrade -u postgres \
-d /var/lib/postgresql/8.4/data -D /var/lib/postgresql/9.0/data \
-b /usr/lib/postgresql-8.4/bin -B /usr/lib/postgresql-9.0/bin
(Qualora ce ne fossero, svolgere tutte le azioni che pg_upgrade dice
all'utente di effettuare.)
$ logout

(Rimuovere i collegamenti simbolici che sono stati creati in
precedenza.)
# rm /var/lib/postgresql/8.4/data/*.conf
# rm /var/lib/postgresql/9.0/data/*.conf
# /etc/init.d/postgresql-9.0 start

Migrazione per versioni precedenti alla 9.0 (con i nuovi ebuild)

I nuovi ebuild dispongono di funzionalità di slotting più avanzate rispetto a quelle degli ebuild precedenti, e pertanto il downtime dovrebbe essere abbastanza ridotto (minuti anzichè ore).

Negli esempi successivi si assume che l'utente stia usando valori predefiniti per i percorsi e le porte, e che stia migrando dalla versione 8.3 alla 8.4. Si prega di modificare opportunamente le istruzioni nel caso in cui ciò non sia vero.

Qualora non lo si abbia ancora fatto, prima di effettuare la migrazione è necessario seguire le instruzioni per l'installazione . Il processo di compilazione potrebbe ridurre le prestazioni del server, ma esso continuerebbe comunque a funzionare.

È necessario modificare un paio di file prima di iniziare con il processo di migrazione. Impostare PGPORT in /etc/conf.d/postgresql-8.4 al valore 6543. In generale va bene ogni valore diverso da quello della porta alla quale prestava ascolto la vecchia versione di PostgreSQL.

Modificare quindi il file /etc/postgresql-8.3/pg_hba.conf in modo tale che solo l'amministratore del database (postgres) possa accedere al cluster tramite il socket Unix.

Codice 5.2: Effettuare la migrazione con i nuovi ebuild

# cp -p /etc/postgresql-8.3/pg_hba.conf /etc/postgresql-8.4/
(Il seguente comando dovrebbe essere sicuro. Leggere la documentazione
per esserne certi.)
#  cp -p /etc/postgresql-8.3/postgresql.conf /etc/postgresql-8.4/
(Non occorre dimenticarsi di copiare ogni altro file di configurazione
di cui si ha bisogno.)

# /etc/init.d/postgresql-8.3 reload
# /etc/init.d/postgresql-8.4 start

(Trasferire i dati dal vecchio cluster a quello nuovo.)
# pg_dumpall -U postgres -p 5432 | psql -U postgres -d postgres -p 6543
# /etc/init.d/postgresql-8.3 stop
# /etc/init.d/postgresql-8.4 stop

(Impostare nuovamente PGPORT al valore 5432.)
# nano -w /etc/conf.d/postgresql-8.4

(Permettere agli utenti di accedere.)
# nano -w /etc/postgresql-8.4/pg_hba.conf
# /etc/init.d/postgresql-8.4 start
# rc-update del postgresql-8.3 && rc-update add postgresql-8.4 default

A questo punto si spera che tutto sia andato per il meglio è che il nuovo server contenga gli stessi dati di quello vecchio.

Migrazione per versioni precedenti alla 9.0 (con i vecchi ebuild)

I vecchi ebuild non possono essere installati contemporaneamente a quelli nuovi. Per questo motivo sarà necessario interrompere l'attività del proprio server per alcune ore. Si consiglia di programmare in anticipo questa operazione ed effettuarla ad esempio nel fine settimana.

Prima di iniziare con la migrazione occorre negare l'accesso al server, in modo tale che non venga fatto alcun cambiamento. È possibile anche che il lettore voglia effettuare il backup dei file postgresql.conf e pg_hba.conf, o di ogni altro file che si reputa importante.

Codice 5.3: Procedimento per effettuare la migrazione dai vecchi ebuild

# pg_dumpall -U postgres > backup_file
# /etc/init.d/postgresql stop
# emerge -C dev-db/postgresql dev-db/libpq dev-db/postgresql-client \
dev-db/postgresql-client
(Seguire il procedimento indicato in questo articolo per installare e
configurare il server.
# /etc/init.d/postgresql-8.4 start
# psql -f backup_file postgres

È possibile che alcuni pacchetti risultino ora corrotti perchè dipendono da quelli che sono stati rimossi, ma dopo aver installato dev-db/postgresql-base e/o dev-db/postgresql-server è possibile eseguire revdep-rebuild in modo tale da reinstallare ogni pacchetto corrotto.

6.  Strumenti

pgAdmin III

pgAdmin III è uno strumento grafico per la gestione di PostgreSQL.

7.  Risoluzione dei problemi

Al server mancano le funzioni strumentali

Questo è un problema facile da risolvere, e la soluzione dipende dalla versione in uso. È necessario importare le funzioni strumentali dal file adminpack.sql. Eseguire il comando corrispondente alla propria versione:

Codice 7.1: Aggiungere le funzioni strumentali per versioni precedenti alla 9.1

# psql -U postgres --file /usr/share/postgresql-9.0/contrib/adminpack.sql

Codice 7.2: Aggiungere le funzioni strumentali per versioni pari o successive alla 9.1

# psql -U postgres -c "CREATE EXTENSION adminpack;"


Stampa

Aggiornato il 13 giugno 2012

La versione originale di questo documento non è più mantenuta

Oggetto: Questa è una guida rapida all'installazione e alla configurazione di PostgreSQL. Le informazioni riportate qui non sostituiscono quelle che si trovano nella documentazione ufficiale, ma sono ad esse complementari.

Aaron W. Swenson
Autore

Mikkel A. Clausen
Redazione

Luca Marturana
Traduzione

Davide Simoncelli
Traduzione

Francesco Turco
Traduzione

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.