Re: [pgbr-geral] Base de dados de CEP
Os Correios tem o direito de comercializar sua base de cep e nós somos livres para comprar ou não. Não é essa a lei de mercado, não é assim que as coisas funcionam? Nada me impede de EU MESMO montar minha base. Formato a base do jeito que achar melhor e pronto! Essa discussão toda me lembrou de um caso que aconteceu há muitos anos envolvendo o método de criptografia PGP desenvolvido pelo Phill Zimmermann. O governo dos EUA proibiram de que o software fosse exportado em forma eletrônica (cd, disquete, download, etc) para qualquer país. No fim um grupo de hackers encontrou uma forma engenosa de burlar a proibição. Lançaram o código do PGP em livro e como não havia restrições na exportação de livros, o código PGP pode ir aos quatro cantos do mundo. O único trabalho era que alguem digitasse o conteúdo do livro. Muito simples! :) Renato ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Melhorar consulta.
Considerando que o retorno deve ser um número, a consulta abaixo pode ser melhorada? SELECT CASE WHEN sum(valor)0 THEN sum(valor) ELSE 0 END FROM cheque_recebido WHERE cliente_id = 15007 Desde já, obrigado por qualquer comentário. Antonio. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Melhorar consulta.
Antonio Prado escreveu: Considerando que o retorno deve ser um número, a consulta abaixo pode ser melhorada? SELECT CASE WHEN sum(valor)0 THEN sum(valor) ELSE 0 END FROM cheque_recebido WHERE cliente_id = 15007 SELECT COALESCE(SUM(valor), 0) FROM cheque_recebido WHERE cliente_id = 15007 -- Euler Taveira de Oliveira http://www.timbira.com/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] LATIN1
Tenho tentado instalar o postgresql na versao 8.3 e não aceita latin1, na versao 8.2 aceitava. Como poderemos resolver este problema? Obrigado Avelino Brun ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problemas com pg_restore
2009/1/17 Euler Taveira de Oliveira eu...@timbira.com Marcelo Costa escreveu: Que o PostgreSQL não usa o /tmp isso é óbvio, porém o SO usa essa partição para descompactar arquivos por padrão antes de efetivamente gravar no disco caso o tamanho do arquivo seja superior ao tamanho da quantidade de memória ram disponivel. e como você mesmo disse sockets Unix. Dependendo de como o dump foi feito, compactações e etc... ele vai sim utilizar o /tmp. E você vai descompactar o que? De acordo com a sua primeira e última frase, você está se contradizendo. Se o SO precisar de memória ele vai recorrer a swap e *não* ao /tmp. Novamente, o problema *não* é o tamanho do /tmp; o pg_restore não descompacta arquivos em locais temporários para depois ler as informações, ele faz isso diretamente utilizando libz ou rotinas de manipulação de arquivos (fopen cia). E se ele não usar o swap o que ele vai usar para descompactar. Você já se perguntou para que serve o /tmp ? *Não* concordo com os seus argumentos. O que pode estar acontecendo é que o arquivo gerado deve ter algum caracter inválido. out of memory caracter inválido. Errado. Erros de out of memory, às vezes, estão relacionados a caracteres inválidos; porque o PostgreSQL calcula de maneira errada a quantidade de memória necessária para uma certa operação. Ainda mais com a versão 7.4, onde não tínhamos uma amarração consistente de configuração regional (aka locale) e codificação de caracteres (aka encoding). É claro que isso pode ter sido causado por problemas no hardware (memória e/ou disco defeituoso). Não me convenceu, Já tive problemas desse tipo com a versão 7.4 e o problema foi causado pela forma como o dump foi gerado que envolvia a compactação do dump e por isso antes do restore o arquivo do dump era descompactado. Thiago se encontrou uma solução nos reporte. Continuo não concordando com o problema de caracteres. -- Marcelo Costa www.marcelocosta.net - Os muito poderosos e os muito estúpidos possuem uma coisa em comum. Ao invés de alterarem as suas visões para se ajustarem aos fatos do mundo, eles alteram os fatos para ajustá-los às suas visões., Doctor Who. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] LATIN1
Bom dia On Sat, Jan 17, 2009 at 12:27 PM, Avelino Brun avel...@databrum.com.brwrote: Tenho tentado instalar o postgresql na versao 8.3 e não aceita latin1, na versao 8.2 aceitava. Como poderemos resolver este problema? Obrigado Avelino Brun Nos informe: 1. Sistema Operacional que você usa 2. Mensagens informadas de erro quando você tenta criar a base -- Marcelo Costa www.marcelocosta.net - Os muito poderosos e os muito estúpidos possuem uma coisa em comum. Ao invés de alterarem as suas visões para se ajustarem aos fatos do mundo, eles alteram os fatos para ajustá-los às suas visões., Doctor Who. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] RES: Base de dados de CEP
o que estou achando estranho em todo esse tema do CEP..que por muito menos o pessoal desce o cano quando alguem pergunta alguma coisa sobre postgreslai moderadores e genios de plantão respondem procura no google..que vc encontra. agora com esse tema do CEP...que A MEU MODO DE ENTENDER ja extrapolou e muito os limites do forum postgresql 2 ou 3 pessoas pediram para parar com esse tema e nao lí nada...(ate porque estou excluindo todo o que tem a ver com CEP e as vezes por engano apago outros tb...) minha sugestao é...quem tiver dúvidas sobre o tema CEP...procure no google e pare de encher caixas postais com esse tema, ou se preferir abra um forum de discussão sobre CEP-BRASIL. Se alguem se sentir incomodado com meu ponto vista, fique a bontade de responder em pvt mailto:t...@nsr.com.br t...@nsr.com.br com o assunto nao concordo com vc..porque tudo o que vier sobre cep ja estou apagandose algum moderador se incomodar tb...fique a bontade de me tirar da lista Santiago NSR Informática. -Mensagem original- De: pgbr-geral-boun...@listas.postgresql.org.br [mailto:pgbr-geral-boun...@listas.postgresql.org.br] Em nome de renato Enviada em: sábado, 17 de janeiro de 2009 09:16 Para: Comunidade PostgreSQL Brasileira Assunto: Re: [pgbr-geral] Base de dados de CEP Os Correios tem o direito de comercializar sua base de cep e nós somos livres para comprar ou não. Não é essa a lei de mercado, não é assim que as coisas funcionam? Nada me impede de EU MESMO montar minha base. Formato a base do jeito que achar melhor e pronto! Essa discussão toda me lembrou de um caso que aconteceu há muitos anos envolvendo o método de criptografia PGP desenvolvido pelo Phill Zimmermann. O governo dos EUA proibiram de que o software fosse exportado em forma eletrônica (cd, disquete, download, etc) para qualquer país. No fim um grupo de hackers encontrou uma forma engenosa de burlar a proibição. Lançaram o código do PGP em livro e como não havia restrições na exportação de livros, o código PGP pode ir aos quatro cantos do mundo. O único trabalho era que alguem digitasse o conteúdo do livro. Muito simples! :) Renato ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] LATIN1
O sitema operacional é windows XP e nao cria esta base dando erro na hora de instalar. From: Marcelo Costa Sent: Saturday, January 17, 2009 11:07 AM To: Comunidade PostgreSQL Brasileira Subject: Re: [pgbr-geral] LATIN1 Bom dia On Sat, Jan 17, 2009 at 12:27 PM, Avelino Brun avel...@databrum.com.br wrote: Tenho tentado instalar o postgresql na versao 8.3 e não aceita latin1, na versao 8.2 aceitava. Como poderemos resolver este problema? Obrigado Avelino Brun Nos informe: 1. Sistema Operacional que você usa 2. Mensagens informadas de erro quando você tenta criar a base -- Marcelo Costa www.marcelocosta.net - Os muito poderosos e os muito estúpidos possuem uma coisa em comum. Ao invés de alterarem as suas visões para se ajustarem aos fatos do mundo, eles alteram os fatos para ajustá-los às suas visões., Doctor Who. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problemas com pg_restore
Marcelo Costa escreveu: E se ele não usar o swap o que ele vai usar para descompactar. Você já se perguntou para que serve o /tmp ? Ugh?! Se a memória se esgotou ele vai utilizar a swap; se a swap acabou você vai ver o SO executando kill() em processos ociosos; e se isso não resolver, você verá insufficient virtual memory. Por algum acaso, você cria arquivos de swap no /tmp? Novamente, bibliotecas de I/O tais como libz e stdio se utilizam de _streams_, ou seja, *não* jogam todo o arquivo aberto na memória. Ao invés disso, elas vão lendo o arquivo aos poucos. Então, é claro que o problema da restauração *não* é memória (física ou virtual). Já tive problemas desse tipo com a versão 7.4 e o problema foi causado pela forma como o dump foi gerado que envolvia a compactação do dump e por isso antes do restore o arquivo do dump era descompactado. Em nenhum momento eu afirmei que o problema seria de caracteres inválidos (vide às vezes no meu e-mail anterior); foi apenas uma suposição de alguém que já enfrentou este problema. -- Euler Taveira de Oliveira http://www.timbira.com/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] LATIN1
Avelino Brun escreveu: Tenho tentado instalar o postgresql na versao 8.3 e não aceita latin1, na versao 8.2 aceitava. Como poderemos resolver este problema? Isso já foi discutido aqui na lista. A partir da 8.3, o PostgreSQL faz uma amarração consistente de configuração regional (aka locale) e codificação de caracteres (aka encoding). Qual o problema em utilizar UTF-8? -- Euler Taveira de Oliveira http://www.timbira.com/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problemas com pg_restore
Thiago se encontrou uma solução nos reporte. Ainda não solucionei o problema, segunda-feira voltarei a tratar deste assunto. Obrigado pelas respostas, estão sendo de grande utilidade. Assim que eu conseguir resolver volto a responder qual foi o processo adotado. 2009/1/17 Marcelo Costa marcelojsco...@gmail.com 2009/1/17 Euler Taveira de Oliveira eu...@timbira.com Marcelo Costa escreveu: Que o PostgreSQL não usa o /tmp isso é óbvio, porém o SO usa essa partição para descompactar arquivos por padrão antes de efetivamente gravar no disco caso o tamanho do arquivo seja superior ao tamanho da quantidade de memória ram disponivel. e como você mesmo disse sockets Unix. Dependendo de como o dump foi feito, compactações e etc... ele vai sim utilizar o /tmp. E você vai descompactar o que? De acordo com a sua primeira e última frase, você está se contradizendo. Se o SO precisar de memória ele vai recorrer a swap e *não* ao /tmp. Novamente, o problema *não* é o tamanho do /tmp; o pg_restore não descompacta arquivos em locais temporários para depois ler as informações, ele faz isso diretamente utilizando libz ou rotinas de manipulação de arquivos (fopen cia). E se ele não usar o swap o que ele vai usar para descompactar. Você já se perguntou para que serve o /tmp ? *Não* concordo com os seus argumentos. O que pode estar acontecendo é que o arquivo gerado deve ter algum caracter inválido. out of memory caracter inválido. Errado. Erros de out of memory, às vezes, estão relacionados a caracteres inválidos; porque o PostgreSQL calcula de maneira errada a quantidade de memória necessária para uma certa operação. Ainda mais com a versão 7.4, onde não tínhamos uma amarração consistente de configuração regional (aka locale) e codificação de caracteres (aka encoding). É claro que isso pode ter sido causado por problemas no hardware (memória e/ou disco defeituoso). Não me convenceu, Já tive problemas desse tipo com a versão 7.4 e o problema foi causado pela forma como o dump foi gerado que envolvia a compactação do dump e por isso antes do restore o arquivo do dump era descompactado. Thiago se encontrou uma solução nos reporte. Continuo não concordando com o problema de caracteres. -- Marcelo Costa www.marcelocosta.net - Os muito poderosos e os muito estúpidos possuem uma coisa em comum. Ao invés de alterarem as suas visões para se ajustarem aos fatos do mundo, eles alteram os fatos para ajustá-los às suas visões., Doctor Who. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Thiago. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Melhorar consulta.
Talvez essa não seja a melhor forma ainda... Imaginemos 3 valores: 2, 3 e -10; o SUM() dessa brincadeira é -5, logo não retornará 0 como o colega estava querendo (ao menos foi o que deixou transparecer), mas sim retornará -5. O COALESCE() retorna o primeiro valor NAO-NULO de uma seqüência de valores. Saludos. On Sat, Jan 17, 2009 at 11:26, Euler Taveira de Oliveira eu...@timbira.comwrote: Antonio Prado escreveu: Considerando que o retorno deve ser um número, a consulta abaixo pode ser melhorada? SELECT CASE WHEN sum(valor)0 THEN sum(valor) ELSE 0 END FROM cheque_recebido WHERE cliente_id = 15007 SELECT COALESCE(SUM(valor), 0) FROM cheque_recebido WHERE cliente_id = 15007 -- Euler Taveira de Oliveira http://www.timbira.com/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Fernando Brombatti email-msn-gtalk-skype: bromba...@gmail.com work: +55 54 3218-6060 home: +55 54 3028-7217 mobile: +55 54 9189-7970 Visite press.datamais.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Melhorar consulta.
Fernando Brombatti escreveu: Talvez essa não seja a melhor forma ainda... Imaginemos 3 valores: 2, 3 e -10; o SUM() dessa brincadeira é -5, logo não retornará 0 como o colega estava querendo (ao menos foi o que deixou transparecer), mas sim retornará -5. O COALESCE() retorna o primeiro valor NAO-NULO de uma seqüência de valores. Mas pelo select dele está falando de cheque_recebido.. nunca vi um cheque com valor menor ou igual a um ... Saludos. On Sat, Jan 17, 2009 at 11:26, Euler Taveira de Oliveira eu...@timbira.com mailto:eu...@timbira.com wrote: Antonio Prado escreveu: Considerando que o retorno deve ser um número, a consulta abaixo pode ser melhorada? SELECT CASE WHEN sum(valor)0 THEN sum(valor) ELSE 0 END FROM cheque_recebido WHERE cliente_id = 15007 SELECT COALESCE(SUM(valor), 0) FROM cheque_recebido WHERE cliente_id = 15007 -- Euler Taveira de Oliveira http://www.timbira.com/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br mailto:pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Fernando Brombatti email-msn-gtalk-skype: bromba...@gmail.com mailto:bromba...@gmail.com work: +55 54 3218-6060 home: +55 54 3028-7217 mobile: +55 54 9189-7970 Visite press.datamais.com http://press.datamais.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Melhorar consulta.
Fernando Brombatti escreveu: Imaginemos 3 valores: 2, 3 e -10; o SUM() dessa brincadeira é -5, logo não retornará 0 como o colega estava querendo (ao menos foi o que deixou transparecer), mas sim retornará -5. O COALESCE() retorna o primeiro valor NAO-NULO de uma seqüência de valores. É claro que foi uma suposição baseado no nome da tabela (cheque_recebido) e campo (valor). Em um modelo de dados consistente o campo 'valor' teria duas restrições (NOT NULL e 0) e, assim, ele não precisaria do COALESCE e nem do CASE. Mas uma coisa é fato: o COALESCE gasta menos ciclos de CPU do que o CASE (acho que era isso que ele queria saber). -- Euler Taveira de Oliveira http://www.timbira.com/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
