On 19-07-2012 23:49, Vinicius Santos wrote:
Desculpe não ter respondido antes, eu estava em deslocamento.
Caramba. São Paulo está tão ruim assim?!
São Paulo tá ruim sim.
Mas no caso de ontem eu tava voltando de um cliente em outra cidade :)
[]s
Flavio Henrique A. Gurgel
Consultor e
2012/7/19 Vinicius Santos vinicius.santos.li...@gmail.com:
Desculpe não ter respondido antes, eu estava em deslocamento.
Caramba. São Paulo está tão ruim assim?!
Há tempos…
Será que já tem a solução?
Não para São Paulo…
___
pgbr-geral mailing
Boa tarde pessoal,
Hoje me deparei com uma situação muito estranha. Temos uma tabela com uma
coluna assim: valor numeric( 14, 4 ) NOT NULL DEFAULT 0.
Quando faço por exemplo: SELECT * FROM tabela WHERE valor = 261.61 tudo
funciona normal, porém quando faço:
SELECT * FROM tabela WHERE valor =
Em 19 de julho de 2012 14:17, Vinicius Santos
vinicius.santos.li...@gmail.com escreveu:
Boa tarde pessoal,
Hoje me deparei com uma situação muito estranha. Temos uma tabela com uma
coluna assim: valor numeric( 14, 4 ) NOT NULL DEFAULT 0.
Quando faço por exemplo: SELECT * FROM tabela WHERE
Funciona normalmente aqui comigo.
Fiz os mesmos testes que você e realmente funciona! Não consegui replicar o
problema dando INSERT manualmente, assim como vc fez.
SELECT * FROM tabela WHERE valor BETWEEN 355.5 AND 355.6;
Caramba, matou a charada. Fiz valores entre 355.55 e 355.56
Agora
Faça um teste e procure por:
SELECT * FROM tabela WHERE valor BETWEEN 355.5 AND 355.6;
Fiz outro teste agora: SELECT * FROM tabela WHERE valor BETWEEN 355.55 AND
355.00; Este não retorna nada.
Porém se eu fizer SELECT * FROM tabela WHERE valor BETWEEN 355.55 AND
355.001, ou
Vc tem algum índice associado a esse campo?
Caso positivo tente rodar um reindex nele e repita seus testes.
Não existe um índice. Mas para testes, eu criei ele, fiz um reindex e nada.
Existe uma CHECK( valor 0 ), então, só pra desencargo de consciência,
removi ela também. Mas o problema
Cria uma cópia da sua tabela e repita os testes nesta nova para ver se o
problema persiste.
CREATE TABLE nova_tabela AS SELECT * FROM tabela;
O problema persiste.
Usando o operador igual, não retorna. Usando o operador BETWEEN retorna.
Mas que coisa hein...
On 19-07-2012 15:23, Vinicius Santos wrote:
Cria uma cópia da sua tabela e repita os testes nesta nova para ver
se o problema persiste.
CREATE TABLE nova_tabela AS SELECT * FROM tabela;
O problema persiste.
Usando o operador igual, não retorna. Usando o operador BETWEEN
Em 19 de julho de 2012 15:32, Flavio Henrique Araque Gurgel
fla...@4linux.com.br escreveu:
O que retorna o comando:
SHOW extra_float_digits;
Provavelmente o PostgreSQL está armazenando mais dígitos internamente do
que está mostrando.
Qual é o tipo de dados do campo?
Mas esse parâmetro
O que retorna o comando:
SHOW extra_float_digits;
O valor é 0.
Provavelmente o PostgreSQL está armazenando mais dígitos internamente do
que está mostrando.
Qual é o tipo de dados do campo?
Numeric(14, 4).
___
pgbr-geral mailing list
E se colocasse uma expressão no where, não funcionaria?
Ex: WHERE (valor+0) = 355.55
Att
Em 19 de julho de 2012 15:40, Vinicius Santos
vinicius.santos.li...@gmail.com escreveu:
O que retorna o comando:
SHOW extra_float_digits;
O valor é 0.
Provavelmente o PostgreSQL está
Provavelmente o PostgreSQL está armazenando mais dígitos internamente do
que está mostrando.
Qual é o tipo de dados do campo?
Numeric(14, 4).
Qual o resultado do comando abaixo:
SELECT sua_coluna/1.00 FROM sua_tabela WHERE suas_condições;
Ajustando para sair o
Em 19 de julho de 2012 15:43, José Mello Júnior jose.mello.jun...@gmail.com
escreveu:
E se colocasse uma expressão no where, não funcionaria?
Ex: WHERE (valor+0) = 355.55
Não resolve, mesma coisa.
Fiz diversos testes. Na tabela original, eu isolei a coluna, exclui todas
as outras colunas
-geral] Comportamento estranho com NUMERIC( 14, 4 )
Em 19 de julho de 2012 15:43, José Mello Júnior jose.mello.jun...@gmail.com
escreveu:
E se colocasse uma expressão no where, não funcionaria?
Ex:
WHERE (valor+0) = 355.55
Não resolve, mesma coisa.
Fiz diversos testes. Na tabela original, eu
Em 19 de julho de 2012 16:01, Claudio Oliveira claudio...@hotmail.comescreveu:
Fala Vinicius,
Tenta assim
where valor = '355.55';
Já vi acontecer isso, acho que corrigiram na 9
Fala Cláudio, blz?
Já tentei assim, não funciona. Ainda não testei com =9.
Em 19 de julho de 2012 16:05, Vinicius Santos
vinicius.santos.li...@gmail.com escreveu:
Fiz assim:
SELECT valor FROM nova_tabela:
--
355.5500
355.5500
Depois:
SELECT valor/1.00 FROM nova_tabela:
On 19-07-2012 16:05, Vinicius Santos wrote:
SELECT sua_coluna/1.00 FROM sua_tabela WHERE suas_condições;
Ajustando para sair o resultado da linha que você está suspeitando?
Fiz assim:
SELECT valor FROM nova_tabela:
--
SELECT sua_coluna/1.00 FROM sua_tabela WHERE suas_condições;
Ajustando para sair o resultado da linha que você está suspeitando?
Eu aumentei o número de zeros da divisão, até que sobrassem zeros à
esquerda.
Assim: SELECT valor/1.0
Em 19 de julho de 2012 16:09, Flavio Henrique Araque Gurgel
fla...@4linux.com.br escreveu:
On 19-07-2012 16:05, Vinicius Santos wrote:
SELECT sua_coluna/1.00 FROM sua_tabela WHERE
suas_condições;
Ajustando para sair o resultado da linha que você está suspeitando?
Logo, o PostgreSQL está agindo corretamente.
Note que o valor armazenado é o que você viu acima.
O que está aparecendo no SELECT seco é um arredondamento apenas na
visualização do valor.
Seu sistema deve ter inserido os dígitos extras.
Não há correção no PostgreSQL nenhuma pro
On 19-07-2012 16:11, Vinicius Santos wrote:
SELECT sua_coluna/1.00 FROM sua_tabela WHERE suas_condições;
Ajustando para sair o resultado da linha que você está suspeitando?
Eu aumentei o número de zeros da divisão, até que sobrassem zeros à
esquerda.
Assim: SELECT
Creio que não esteja correto não, porque o tipo de dado da coluna dele é
NUMERIC(14,4) e parece que ele não está respeitando essa precisão... fiz
alguns testes aqui e não consegui reproduzir aquele comportamento:
Também concordo com você. Ele deveria dar um erro para valores tão grandes
On 19-07-2012 16:21, Vinicius Santos wrote:
Creio que não esteja correto não, porque o tipo de dado da coluna
dele é NUMERIC(14,4) e parece que ele não está respeitando essa
precisão... fiz alguns testes aqui e não consegui reproduzir aquele
comportamento:
Também concordo
O PostgreSQL tem uma resolução alta interna para o tipo numeric.
Provavelmente o valor foi resultado de um cálculo que gerou os decimais
que você está vendo.
Recomendo que, na sua aplicação ou nas consultas que está fazendo,
arredonde os valores no momento da operação de INSERT ou UPDATE.
Provavelmente se alguém entrar na hackers e indicar que isso é um bug
vai tomar toco do Tom Lane.
Tudo bem, concordo que não é um bug. Mas inserindo o mesmo valor por
pgAdmin ele aparentemente trunca em 4 posições.
Porque não truncaria em outra aplicação cliente ? Seja qual for ela...
On 19-07-2012 16:33, Vinicius Santos wrote:
Provavelmente se alguém entrar na hackers e indicar que isso é um bug
vai tomar toco do Tom Lane.
Tudo bem, concordo que não é um bug. Mas inserindo o mesmo valor por
pgAdmin ele aparentemente trunca em 4 posições.
Porque não truncaria
Fiz um teste com 9.1.4 aqui via psql.
Os valores foram devidamente arredondados (não truncados) no INSERT.
Pergunto:
Versão do seu PostgreSQL?
Arquitetura (32 ou 64 bits) e S.O. (existem bugs que podem estar
relacionados ao endianess do processador).
Vamos lá:
Versão: 8.4.12 -
Em 19 de julho de 2012 16:53, Vinicius Santos
vinicius.santos.li...@gmail.com escreveu:
Fiz um teste com 9.1.4 aqui via psql.
Os valores foram devidamente arredondados (não truncados) no INSERT.
Pergunto:
Versão do seu PostgreSQL?
Arquitetura (32 ou 64 bits) e S.O. (existem bugs que podem
Bom, vou tentar fugir um pouco do PostgreSQL e ir para o mundo do C.
No C é comun compararmos igualdade de float/double da seguinte forma:
#define EPS 0.1 // precisão
if (valor = 355.55 - EPS valor = 355.55 + EPS) {
// valor igual
} else {
// valor diferente
}
Explicando, o
Em 19/07/12, Matheus de Oliveiramatioli.math...@gmail.com escreveu:
Bom, vou tentar fugir um pouco do PostgreSQL e ir para o mundo do C.
No C é comun compararmos igualdade de float/double da seguinte forma:
#define EPS 0.1 // precisão
if (valor = 355.55 - EPS valor = 355.55 + EPS)
Em minha opinião, o presente caso só pode ser atribuído à alteração do
tipo de dados da base. Para mim não ficou claro se o Vinicius
recarregou a tabela após a modificação ou fez um update com a cláusula
USING no comando ALTER TABLE.
Osvaldo. Eu fiz um ALTER TABLE sem a cláusula USING.
Sim. Eu perguntei porque fiz uma pesquisa nos fóruns da hackers e mais
pessoas tiveram esse problema na conversão automática.
Desculpe não ter respondido antes, eu estava em deslocamento.
Caramba. São Paulo está tão ruim assim?!
Será que já tem a solução? Vou dar uma pesquisada na -hackers
Em 19 de julho de 2012 23:38, Flavio Henrique Araque Gurgel
fla...@4linux.com.br escreveu:
[...]
Mas eu ainda questiono, mesmo após fazer a alteração da tabela, e
tal...Porque será que acontece isso? Alguma coisa aconteceu na hora da
conversão.
É a explicação do Oswaldo. Você mudou a
O código está em src/backend/util/adt/numeric.c.
Com a replicação fácil do problema, alguém poderá depurar. Ou pelo menos
apontar o erro, se pode ser um erro do processador, S.O ou de alguma
biblioteca. Parece ser um caso interessante.
___
pgbr-geral
35 matches
Mail list logo