Novità -- problema Cinese in DB UTF8

Allora,
ho fatto i seguenti passi:
1. ho modificato i template in modo che anche essi siano:

Name | Owner | Encoding | Collate | Ctype | Access privileges
----------+-------+----------+-------------+-------------+-------------------
postgres | pedro | UTF8 | it_IT.utf-8 | it_IT.utf-8 |
mioDB | pedro | UTF8 | it_IT.utf-8 | it_IT.utf-8 |
template0 | pedro | UTF8 | it_IT.utf-8 | it_IT.utf-8 |
template1 | pedro | UTF8 | it_IT.utf-8 | it_IT.utf-8 |

Non mi piacciono i nomi di nazioni o lingue per del testo universale, ma da quanto ho capito, qualsiasi collate o Ctype/Collate che finisce per utf-8 va bene (+ dettagli nella guida in PS che metto perché può essere utile a qualcuno).

2. ho fatto un dump. Siccome non avevo memoria sufficiente, ho dovuto farlo compresso:
pg_dump dbname | gzip > filename.gz3. ho quindi eliminato mioDB e l'ho ricreato come si vede sopra, con collate e Ctype corretti

4. quindi cerco di rimettere i dati nel DB:
gunzip -c filename.gz | psql dbnamema il DB risulta vuoto a dispetto della lunghezza dell'operazione e l'assenza di errori. Usare il metodo
cat filename.gz | gunzip | psql dbnamenon cambia niente. Entrambi sono su http://www.postgresql.org/docs/9.1/static/backup-dump.html
mioDB=# \dv
No relations found.

Se avete qualche idea...
Francesco

PS
per convertire i template dò questa procedura, che in italiano non facilmente si trova. Devo fare una forte critica a google, che nonostante avessi fatto delle ricerche usando parole chiave simili, non mi ha portato alle pagine con questa procedura. Credo sia a causa delle ricerche personalizzate che fanno arrivare utenti diversi a risultati diversi, ma così facendo oscurano una parte del web o la rendono più irraggiungibile, come per me la pagina https://gist.github.com/ffmike/877447 -- dalla quale mi sono ispirato e che ho completato per modificare anche i collate e ctype dei template:

postgres # update pg_database set datallowconn = TRUE where datname = 'template0';
postgres # \c template0
template0 # update pg_database set datistemplate = FALSE where datname = 'template1';
template0 # drop database template1;
template0 # create database template1 with template = template0 encoding = 'UTF8' LC_COLLATE = 'it_IT.utf-8' LC_CTYPE = 'it_IT.utf-8';
template0 # update pg_database set datistemplate = TRUE where datname = 'template1';
template0 # \c template1
template1 # drop database template0;
template1 # create database template0 with template = template1 encoding = 'UTF8' LC_COLLATE = 'it_IT.utf-8' LC_CTYPE = 'it_IT.utf-8';
template1 # drop database postgres;
template1 # create database postgres with template = template1 encoding = 'UTF8' LC_COLLATE = 'it_IT.utf-8' LC_CTYPE = 'it_IT.utf-8';
template1 # update pg_database set datallowconn = FALSE where datname = 'template0';

(idem se usate altri template per sapere i formati supportati dalla vostra macchina, ad esempio it_IT.utf-8 digitate il comando locale, ovviamente su linux)

Invita i tuoi amici e Tiscali ti premia! Il consiglio di un amico vale più di uno spot in TV. Per ogni nuovo abbonato 30 € di premio per te e per lui! Un amico al mese e parli e navighi sempre gratis: http://freelosophy.tiscali.it/

On Wed, Aug 14, 2013 at 09:45:28AM +0200, ciifrancesco(at)tiscali(dot)it wrote:
> Allora,
> ho fatto i seguenti passi:
> 1. ho modificato i template in modo che anche essi siano:
>
> Name | Owner | Encoding | Collate | Ctype | Access privileges
> ----------+-------+----------+-------------+-------------+-------------------
> postgres | pedro | UTF8 | it_IT.utf-8 | it_IT.utf-8 |
> mioDB | pedro | UTF8 | it_IT.utf-8 | it_IT.utf-8 |
> template0 | pedro | UTF8 | it_IT.utf-8 | it_IT.utf-8 |
> template1 | pedro | UTF8 | it_IT.utf-8 | it_IT.utf-8 |

È fortemente sconsigliato alterare template0, che infatti non può
essere alterato senza seguire procedure discutibili come quella
riportata in calce.

Se non si vuole o può usare il template di default template1, che
infatti è editabile, si può fare una copia di template0 e poi alterare
questa copia. Funziona ugualmente, dal momento che nel creare un nuovo
database si può usare un qualsiasi database come template.

> 4. quindi cerco di rimettere i dati nel DB:
> gunzip -c filename.gz | psql dbnamema il DB risulta vuoto a dispetto della lunghezza dell'operazione e l'assenza di errori. Usare il metodo
> cat filename.gz | gunzip | psql dbnamenon cambia niente. Entrambi sono su http://www.postgresql.org/docs/9.1/static/backup-dump.html
> mioDB=# \dv
> No relations found.

Non è possibile che, in assenza di errori, i dati non siano stati
ripristinati. Quasi sicuramente le nuove tabelle sono state create in
degli schemi che non sono contenuti nel search_path, e quindi non sono
visibili con un semplice "\dv".

Con "\dn" si vedono tutti gli schemi disponibili.

Riferimenti su search_path:

http://www.postgresql.org/docs/9.3/static/ddl-schemas.html#DDL-SCHEMAS-PATH

Cordiali saluti,
Dr. Gianni Ciolli - 2ndQuadrant Italia
PostgreSQL Training, Services and Support
gianni(dot)ciolli(at)2ndquadrant(dot)it | www.2ndquadrant.it

Hi Michel,

On Fri, Aug 16, 2013 at 02:03:51PM +0200, Michel van der Grinten wrote:
> It's just that we dont speak Italian that well.

This is an Italian-speaking mailing list, which you must have
subscribed by mistake ;-)

> Or you translate in English other wise please get me off this
> mailinglist, as I don't understand.

I am not the mailing list manager, just a member. I think you should
unsubscribe your address from this list:

http://www.postgresql.org/community/lists/subscribe/

and then consider subscribing other PostgreSQL mailing list:

http://www.postgresql.org/community/lists/

Best wishes,
Dr. Gianni Ciolli - 2ndQuadrant Italia
PostgreSQL Training, Services and Support
gianni(dot)ciolli(at)2ndquadrant(dot)it | www.2ndquadrant.it