Lavorando su un postgres vecchiotto avevo scritto una riga di codice php che con le nuove versioni non è accettata per questioni di casting.
Visto che in effetti il risparmio è notevole, oltre che più corretto, segnalo la funzione TO_CHAR (che ha nelle opzioni quello che spesso serve per fare manipolazioni di date).

Quello che prima era trovato concatenando due stringhe ricavate da DATE_PART (per prendere una parte di un timestamp without date zone) e facendolo passare per LPAD in due cifre riempito con caratteri 0:

( LPAD( DATE_PART('day',file_upped), 2,'0') ||
    LPAD( DATE_PART('month',file_upped), 2,'0') )

ora è trovato con questa semplice funzione che ha fra le opzioni già la possibilità di avere giorno e mese in campo di 2 cifre:

TO_CHAR(file_upped,'DDMM')

Mea culpa. Negli ultimi mesi ho dovuto dare un occhio in più alle query SQL e così sto ripassando e imparando un sacco di cose che prima mi erano sconosciute.

Una robba estremamente utile che prima facevo (male) “tagliando” in perl i dati fetch’ati dal database è prendere raggruppamenti di dati gruppati secondo una clausola.

La sostanza è che ultimamente mi ero ritrovato molto a mio agio nel raggruppare dati grazie all’opzione GROUP BY conteggiando le voci con COUNT. Il problema era che non sapevo come fare un taglio sul conteggio, e così scremavo i dati in perl dopo averli raccolti tutti dal database.
Questa cosa palesemente non risultava buona.
Quindi dopo prezioso suggerimento ho letto questa paginetta e ho trovato HAVING. Niente di trascendentale, ma per me salvifico.

 => SELECT nome, COUNT(*) FROM lista
       GROUP BY nome HAVING COUNT(*) > 600 ORDER BY count DESC;

Dopo aver filtrato (eventualmente) i dati con WHERE, l’input derivato dalla tabella può essere soggetto al GROUP BY per raggruppare dati, e i raggruppamenti possono essere scremati dalla clausola HAVING.
GROUP BY viene utilizzato per raggruppare insieme quelle righe della tabella che condividono gli stessi valori in tutte le colonne selezionate.
I raggruppamenti vanno d’accordo con funzioni che aggregano espressioni – come SUM() o COUNT().

Piccole scoperte per grandi pivelli.

Avevo necessità di ricopiare una tabella già fatta da un database postgres (8.3) ad un altro.
Come fare per avere la stessa linea “CREATE” se l’history non riesce a recuperare così tanto indietro nel tempo?
Semplice: usare pg_dump.

pg_dump è l’utility per fare il backup dei database Postgres. Con un paio di opzioni, ha fatto perfettamente al caso mio:

# pg_dump nome_database --schema-only -t nome_tabella

L’opzione -t o –table serve a specificare la tabella che abbiamo scelto, e –schema-only dumpa solo la definizione dei data (non i dati stessi).

Senza specificare un output, pg_dump spamma su STDOUT, quindi con un taglia e incolla il gioco è fatto.

Un bigint occupa 8 bytes.
Dal manuale di postgres:

bigint
8 bytes
large-range integer
range: -9223372036854775808 to 9223372036854775807

Hai voglia, oh caro spammatore, a riempirmi di record.

A forza di pistolare sui db, sto provando un po’ di tutto per vedere dove mi trovo meglio.
Un db importante sul fronte opensource è PostgreSQL (sito ufficiale e wiki per un po’ di storia).

Per creare utenze all’interno del sistema postgres è possibile utilizzare programmi da shell (createuser) o comandi da prompt (CREATE ROLE utente).
Per avere un’idea dei ruoli creati si puo’ fare un select sulla tabella pg_roles del db postgres (di default)…

postgres=# SELECT rolname FROM pg_roles ;
 rolname
----------
 postgres
 odg
(2 rows)

oppure usare il semplice comando \du

postgres=# \du
                               List of roles
 Role name | Superuser | Create role | Create DB | Connections | Member of
-----------+-----------+-------------+-----------+-------------+-----------
 odg       | no        | no          | no        | no limit    | {}
 postgres  | yes       | yes         | yes       | no limit    | {}
(2 rows)

(Come si vede ho creato un ruolo extra (odg) oltre a quello di default.)

More »