Newsgroup: it.comp.software.database
Titolo: postgresql notazione decimale

essendo le prime volte che uso un db postgresql mi sono trovato davanti ad
un problema.
mi hanno fornito un dump di una tabella che però non riesco ad importare, si
ferma qua:
test=# copy articoli from '/home/httpd/html/articoli.txt';
ERROR:  copy: line 1, pg_atoi: error in "1.213700": can't parse ".213700"
pare che il database non sia "impostato" sul punto decimale ma sulla
virgola, come si può fare per cambiare questo comportamento in un database
già popolato?
grazie,
kain

Forse puoi provare a cambiare il locale della macchina sui cui gira postgres ed impostarlo in italiano..
Saluti
Fabrizio Mazzoni


>
prova a dare
 > set LC_NUMERIC = 'en_US'
e poi ritenta la copy.
bye!
-- 
Fabrizio "Hermooz" Ermini


grazie per l'hint ma:
maxgest=# \set
VERSION = 'PostgreSQL 7.3.4 on i686-pc-linux-gnu, compiled by GCC gcc (GCC)
3.3'
DBNAME = 'maxgest'
USER = 'postgres'
PORT = '5432'
ENCODING = 'LATIN1'
PROMPT1 = '%/%R%# '
PROMPT2 = '%/%R%# '
PROMPT3 = '>> '
HISTSIZE = '500'
LC_NUMERIC = 'en_US'
maxgest=# \copy articoli from '/home/httpd/html/articoli.txt'
\.
ERROR:  copy: line 1, pg_atoi: error in "1.213700": can't parse ".213700"
lost synchronization with server, resetting connection
maxgest=#
ho provato a tenere encoding sql_ascii ma niente da fare, ieri lurkando un
pò per google ho trovato che in molti esportano dati e non li possono
importare per via di questo errore.
si dividono in due, quelli a cui non accetta caratteri di terminazione riga
e quelli come me nel cui caso un solo punto viene interpretato male.
a proposito, come si fa a salvare i dati inseriti con un \set ? se chiudo
psql si perdono nel nulla.
cavoli.. dovrei fare un lavoro urgente e fermarsi davanti a ste cose è
veramente brutto :(
kain

 psql si perdono nel nulla.
Tutto ciò che definisci "al volo" con un set lo puoi anche definire 
"permanentemente" nel file di configurazione...


già popolato?
Non credo sia quello il problema. La funzione che crolla e' pg_atoi, dove
"atoi" significa Ascii TO Integer.
Sembrerebbe che non si aspetti un formato float.
Non e' che, magari, stai importando un valore in Euro (float) in un campo
Lire (integer)?
$ select 1 + '7.34';
ERROR:  pg_atoi: error in "7.34": can't parse ".34"
$ select 1.6 + '7.34';
 ?column?
----------
     8.94
(1 row)
$  select 1.6 + '7.34X';
ERROR:  Bad float8 input format '7.34X'
Se si aspettasse un float, userebbe pg_atof e non pg_atoi.
Leonardo
-- 
Nach doiligh domhsa mo chailin a mholadh
'S ni he amhain mar bhi si or
Bhi si mar gath greine a dhul in eadan na gloinne
Is bhi sceimh mhna na finne le mo cailin or

 Se si aspettasse un float, userebbe pg_atof e non pg_atoi.
questo è un dump che mi hanno fornito di un database già popolato, la
persona che ha creato il database mi ha risposto così:
Dovresti provare a creare il database senza opzioni,
da un altro database: CREATE DATABASE NOMEDB;
e poi caricare il pgdump.
In effetti il pgdump che ti ho dato conteneva gia' il file articoli che
probabilmente non e' stato caricato per la differenza di convenzione sul
punto decimale.
non mi pare questa la soluzione, controllo meglio e vi faccio sapere,
grazie.
kain

non mi pare questa la soluzione
I stand my case. Ho provato con PostgreSQL 7.1, e ottengo esattamente
l'errore che lamenti tu se provo a importare un campo FLOAT dentro un
campo INT.
=# CREATE TABLE test_float ( x float );
CREATE
=# CREATE TABLE test_int ( x integer );
CREATE
=# INSERT INTO test_int VALUES ( 12 );
INSERT 54495816 1
=# COPY test_int to '/tmp/test.txt';
COPY
=# COPY test_float FROM '/tmp/test.txt';
COPY
=# COPY test_float TO '/tmp/test.txt';
COPY
=# COPY test_int FROM '/tmp/test.txt';
COPY
=# UPDATE test_float SET x=3.1415;
UPDATE 1
=# COPY test_float TO '/tmp/test.txt';
COPY
=# COPY test_int FROM '/tmp/test.txt';
ERROR:  copy: line 1, pg_atoi: error in "3.1415": can't parse ".1415"
E d'altro canto, ammettiamo che esista un formato SQL in cui i numeri
hanno la virgola come separatore decimale.
Se cosi' fosse, il comando
INSERT INTO test VALUES ( 1,3 );
cosa significa... inserire una colonna FLOAT che vale 1.3, o inserire
due colonne di valori 1 e 3, rispettivamente? Si introdurrebbe quella
che e' una pericolosa ambiguita', che si verificherebbe solo in certi
locale. Secondo me, non regge.
Prova a dare il comando
\d articoli
dal database esportante e dal database ricevente. Scommetto che trovi
una colonna INTEGER mentre nel database esportante hai FLOAT, MONEY o
comunque un formato che prevede la virgola.


 comunque un formato che prevede la virgola.
Il baco potrebbe anche essere che, IIRC, in postgres i tipi NUMERIC o 
DECIMAL sono trattati come interi se non è espressamente richiesto di 
avere cifre decimali (i.e. tipo NUMERIC(10,2)), a differenza di altri DB 
dove il tipo numerico di default è float. Dato che stiamo a parlare di 
trasposizioni da un DB a un altro...



è vero, sul database fornitomi i campi sono in formato INT.
la mia domanda però è, come è possibile che abbiano funzionato fin'ora?
magari facevano i copy e poi non hanno mai provato a reimportarli?
secondo te mettendoci una virgola è possibile aggirare il problema o c'è
modo di fargli accettare comunque questo campo senza stravolgere la
struttura?
grazie ancora,
kain

struttura?
No. Devi crearti una seconda tabella identica ad 'articoli' ma con i
campi FLOAT.
Poi importi dentro ad "articoli2":
DELETE FROM articoli;
DELETE FROM articoli2;
COPY articoli2 from 'test.txt';
INSERT INTO articoli SELECT * FROM articoli2;
DELETE FROM articoli2;
Cosi' funziona (provato adesso)
root=> select * from test_float;
   x
--------
 3.1415
(1 row)
root=> select * from test_int
root-> ;
 x
----
 12
 12
(2 rows)
root=> insert into test_int select * from test_float;
INSERT 54495819 1
root=> select * from test_int;
 x
----
 12
 12
  3		<--------------
(3 rows)
Nota bene: se per disgrazia quei campi float sono monetari, sei nei
casini, perche' rischi che ti sballino di brutto i conti alla fine.
Sarebbe importantissimo capire A COSA SERVONO quei campi float!





No, in questo caso il campo che importa prende sempre un tipo float (anzi
passa da una funzione apposta, cash_in()).
Puo' esserci un problema pero', come dici, se il campo che "prende" e' di
tipo MONEY. In questo caso:
create table x ( x money );
insert into x values ('5,390.12');
\copy x to 'test.txt'
ottengo un file contenente
$5,390.12
che non e' detto sia parsabile (anzi di sicuro NON LO E') in locale altri
che en_US.
