Em 18 de julho de 2012 20:25, Edson - Listas edson...@gmail.com escreveu:
Olá Tiago,
Poderia dar mais detalhe, de como usar o pg_dump sem dados com o KDiff.
Basicamente, você precisa ter um controle de demandas (sobre o que é
criado). Crie um planejamento de versões e releases do modelo, assim
2012/7/19 Tiago Adami adam...@gmail.com
Em 18 de julho de 2012 20:25, Edson - Listas edson...@gmail.com
escreveu:
( ... )
Um pitaco adicional: já passei por diversas discussões a respeito
(inclusive com o meu amigo Rodrigo Della Justina com o qual tive o
prazer de trabalhar em 2 empresas
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
Fala Vinicius,
Tenta assim
where valor = '355.55';
Já vi acontecer isso, acho que corrigiram na 9
Abraços t+
Claudio Oliveira
http://www.msisolucoes.com.br
Date: Thu, 19 Jul 2012 15:59:31 -0300
From: vinicius.santos.li...@gmail.com
To: pgbr-geral@listas.postgresql.org.br
Subject: Re:
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.
Boa noite pessoALL.
Estou com a seguinte necessidade: eu preciso descobrir quais são as
constraints de foreign-key
que estão fazendo referencia à tabelaX(colunaPK) ?
Meu banco de dados contém vários schemas e cada um, muitas tabelas. Então,
por meio de
pgadmin, está meio desumano entrar em cada
2012/7/19 Marcos Aurelio Nobre marcono...@gmail.com
Boa noite pessoALL.
Estou com a seguinte necessidade: eu preciso descobrir quais são as
constraints de foreign-key
que estão fazendo referencia à tabelaX(colunaPK) ?
Meu banco de dados contém vários schemas e cada um, muitas tabelas.
No psql \dt schema.tabela
Em 19/07/2012 21:25, Matheus de Oliveira matioli.math...@gmail.com
escreveu:
2012/7/19 Marcos Aurelio Nobre marcono...@gmail.com
Boa noite pessoALL.
Estou com a seguinte necessidade: eu preciso descobrir quais são as
constraints de foreign-key
que estão fazendo
ou \d+ schema.tabela
Em 19/07/2012 21:29, Bruno Silva bemanuel...@gmail.com escreveu:
No psql \dt schema.tabela
Em 19/07/2012 21:25, Matheus de Oliveira matioli.math...@gmail.com
escreveu:
2012/7/19 Marcos Aurelio Nobre marcono...@gmail.com
Boa noite pessoALL.
Estou com a seguinte
BINGO !
Esse SELECT mata-a-pau o que preciso !
Valeu Matheus, é exatamente isso.
Aproveitando..
Como eu acredito que no PostgreSQL não há como desativar uma
FK-constraint então se eu quisesse deletar as constraints que são listadas
na coluna 1 dessa query eu deveria excluir da relação :
Bruno, boa noite.
Isso ai que vc postou não resolve a minha questão - não.
O \dt schema. lista as tabelas (relations) contidas no schema.
Se enviarmos \dt schema.tabela somente esta tabela (relação) será
listada
Será que vc não confundiu a palavra relations com a idéia de as
Bruno,
Ok, o \D+ schema.tabela lista o que preciso mas tbm muita informação que
não preciso.
O SELECT no catalogo (aka system-tables) que o Matheus postou é mais direto
e preciso.
De toda sorte , muito grato pela ajuda e diligência.
MN
Em 19 de julho de 2012 21:30, Bruno Silva
2012/7/19 Marcos Aurelio Nobre marcono...@gmail.com:
Se fosse no jargão da Álgebra Relacional, ouviríamos a palavra Tupla
referindo-se ao que conhecemos
como tabelas do banco de dados.
Errado!
___
pgbr-geral mailing list
Em 19 de julho de 2012 21:50, Marcos Aurelio Nobre
marcono...@gmail.comescreveu:
[...]
Se fosse no jargão da Álgebra Relacional, ouviríamos a palavra Tupla
referindo-se ao que conhecemos
como tabelas do banco de dados.
[...]
Vc quis dizer Linha ou Registro né... pq uma tabela é tb
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
44 matches
Mail list logo
