On 26-07-2012 00:50, Danilo Silva wrote:
> Reparei que o banco de dados da minha máquina retorna as mensagens em
> português, já o servidor de produção retorna em inglês. Isso tem
> alguma relação com o parâmetro "lc_messages"?
>
Se o código for compilado com suporte a NLS (--enable-nls), você po
2012/7/26 Danilo Silva :
>
> Reparei que o banco de dados da minha máquina retorna as mensagens em
> português, já o servidor de produção retorna em inglês. Isso tem alguma
> relação com o parâmetro "lc_messages"?
Inclusive.
___
pgbr-geral mailing list
p
Pessoal, uma dúvida.
Reparei que o banco de dados da minha máquina retorna as mensagens em
português, já o servidor de produção retorna em inglês. Isso tem
alguma relação com o parâmetro "lc_messages"?
Att.
Em 26 de julho de 2012 00:43, Danilo Silva escreveu:
>
>
> Em 25 de julho de 2012 23:45,
Em 25 de julho de 2012 23:45, Guimarães Faria Corcete DUTRA, Leandro <
l...@dutras.org> escreveu:
> 2012/7/25 Danilo Silva :
> >
> > Li, há um tempo, sobre os códigos de erros (tabela SQL state)
>
> Leu onde? Não é uma tabela!
>
google, como disse antes, foi há um tempo, não recordo o lugar, mas
2012/7/25 Danilo Silva :
>
> Li, há um tempo, sobre os códigos de erros (tabela SQL state)
Leu onde? Não é uma tabela!
> mas não achei
> nada específico para o postgres, pois em alguns testes, o código + mensagem
> gerado pelo postgres não coincidia com o código + mensagem dessa tabela.
Mais u
Pessoal,
Como posso fazer para extrair a mensagem de erro de uma query (um insert
por exemplo) e exibi-la na aplicação? O postgres está na versão 8.2 (não
podemos migrar no momento para a 9.1) e a aplicação em PHP.
Da forma como está atualmente só conseguimos saber se a query foi executada
com su
> "Vinicius" == Vinicius Santos writes:
Vinicius> Certo. O que quis dizer é que o select está literamente passando
Vinicius> todos os registros da tabela de produto. Eu comprovei isto assim:
Vinicius> SELECT chave, produto, funcao_teste( chave ) FROM visao WHERE
produto
Vinic
> Cara, cuidado!
>
> "Seq scan" não é sinônimo de lentidão. Como o Tiago disse, caso a tabela
> produtos não seja muito grande (e.g. algumas páginas) é natural que o
> PostgreSQL escolha um "seq scan" ao invés de um "index scan", já que o
> "index scan" poderia acarretar mais leituras em disco que
2012/7/25 Vinicius Santos
>
>> Com "IN" esse comportamento é bem comum. O IN é bom para um conjunto
>> limitado de valores. Por exemplo, produto in (10, 20, 40, 50). Fazer
>> IN para "juntar" tabelas não é a melhor opção.
>> Tente fazer um join, mais ou menos assim:
>>
>
> Estou utilizando o IN c
>
>
> Com "IN" esse comportamento é bem comum. O IN é bom para um conjunto
> limitado de valores. Por exemplo, produto in (10, 20, 40, 50). Fazer
> IN para "juntar" tabelas não é a melhor opção.
> Tente fazer um join, mais ou menos assim:
>
Estou utilizando o IN com um conjunto bem limitado de val
Em 25 de julho de 2012 14:38, Vinicius Santos
escreveu:
>
> Nossas estatísticas estão atualizadas, já tentei mudar a consulta de várias
> formas, mas preciso utilizar o operador IN.
Por que precisa utilizar o IN? De acordo com o número de registros o
PostgreSQL é inteligente o suficiente para esc
> até aqui legal. Porém quando faço:
>
> SELECT chave, produto FROM visao WHERE produto IN ( SELECT codigo FROM
> produtos_contados ),
>
> o plano de execução muda radicalmente neste segundo caso, no segundo caso
Com "IN" esse comportamento é bem comum. O IN é bom para um conjunto
limitado de val
Boa tarde pessoal,
Tenho uma view criada assim:
CREATE VIEW visao AS SELECT chave AS produto, produto FROM produtos;
Então eu faço um select assim:
SELECT chave, produto FROM visao WHERE produto = 1234;
até aqui legal. Porém quando faço:
SELECT chave, produto FROM visao WHERE produto IN ( S
13 matches
Mail list logo
