> 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-ger
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. V
> 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 -hack
On 19-07-2012 20:45, Vinicius Santos wrote:
> Osvaldo. Eu fiz um ALTER TABLE sem a cláusula USING. Pois converti de um
> NUMERIC( 18, 2 ) para um de NUMERIC( 14, 4 ). Todos os testes estão nos
> emails anteriores.
>
> Pois bem, agora em casa, estou fazendo uns testes também. Criei uma nova
> tabel
Em 19 de julho de 2012 21:50, Marcos Aurelio Nobre
escreveu:
>
> [...]
>
> 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 conhecida co
2012/7/19 Marcos Aurelio Nobre :
>
> 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
pgbr-geral@listas.postgresql.org.br
https:/
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 escreveu:
> ou
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 (relação) será
listada
Será que vc não confundiu a palavra "relations" com a idéia de "as relações
q
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 :
PG
ou \d+ schema.tabela
Em 19/07/2012 21:29, "Bruno Silva" escreveu:
> No psql \dt schema.tabela
> Em 19/07/2012 21:25, "Matheus de Oliveira"
> escreveu:
>
>>
>> 2012/7/19 Marcos Aurelio Nobre
>>
>>> Boa noite pessoALL.
>>>
>>> Estou com a seguinte necessidade: eu preciso descobrir quais são as
>>
No psql \dt schema.tabela
Em 19/07/2012 21:25, "Matheus de Oliveira"
escreveu:
>
> 2012/7/19 Marcos Aurelio Nobre
>
>> 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) ?
2012/7/19 Marcos Aurelio Nobre
> 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
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
>
> 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
Em 19/07/12, Matheus de Oliveira 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) {
> // valo
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 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 bug
> 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 - A
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 tr
> 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...
_
> 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 UPDAT
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 co
>
>
> 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 grande
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: SE
> 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 compo
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á su
>
> 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.00
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:
> ---
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:
> ---
Em 19 de julho de 2012 16:01, Claudio Oliveira escreveu:
> 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.
__
> 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:
--
355.5500
355.5500
Depois:
SELECT valor/1.
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: [pgbr-ger
Em 19 de julho de 2012 15:43, José Mello Júnior 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 deixando apenas a coluna
> 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
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 PostgreS
> 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 lis
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 es
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 BETWE
>
> 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...
___
>
> 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 prob
>
> 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.0
> 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
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 tab
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
2012/7/19 Tiago Adami
> Em 18 de julho de 2012 20:25, Edson - Listas
> 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 diferentes e também participa
Em 18 de julho de 2012 20:25, Edson - Listas 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
como você faria
46 matches
Mail list logo
