Re: [pgbr-geral] Quais discos usar ?
2015-07-31 16:11 GMT-03:00 Vinícius Aquino do Vale aquino.v...@gmail.com: Considerando seu ambiente misto. Eu trabalharia com disco físico e ssd. Isso não faz muito sentido, com apenas 200 GB. Para ter alguma confiabilidade, ele precisaria de ter um Raid de discos, e um de unidades SSD. Como tudo que ele tem cabe num espelho de unidades SSD de 256 GiB, não precisa disco físico, seria um gasto adicional com pouquíssimo ganho em termos de distribuição de carga, e possivelmente o sistema como um todo fique até mais lento. Melhor pegar o valor dos discos e botar em processaores com mais cache, ou mais memória. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Quais discos usar ?
2015-07-31 16:37 GMT-03:00 Sebastian Webber sebast...@swebber.me: Falando em preço, normalmente 1 SSD tem um preço muito maior que um HD SAS 15k. Não tenho idéia precisa dos valores, mas a bem pouco tempo atrás o valor era absurdo (tipo 1 SSD custava 6 discos SAS). Isso vai fazer muita diferença na hora de comprar o servidor. Ceteris paribus, vero. Mas qual o menor SAS que se consegue comprar hoje que cobre a necessidade de 200 GB? Provavelmente a diferença não é tão grande assim, se levarmos em conta a necessidade real de armazenamento. Claro que sempre será possível montar primeiro o sistema, economizando, e observando o comportamento decidir onde investir melhor em atualizações. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Quais discos usar ?
2015-07-30 16:20 GMT-03:00 Tiago José Adami adam...@gmail.com: Agora, tenha em mente que o custo de um SSD para servidor é alto. Sim. Talvez você possa investir em 2 discos de SAS 15.000 RPM para configurar um RAID 1 Três. Precisa ter um estepe, se quiser ter alta confiabilidade e disponibilidade. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Quais discos usar ?
2015-07-30 15:08 GMT-03:00 Raphael Coutinho rcoutosi...@gmail.com: Pelo que vi a vida útil do SSD é bem inferior. Não existe ‘o’ SSD. Há uma enorme variedade de marcas, linhas e modelos, em toda faixa de custo e com todo tipo de característica diferente. É claro que você não vai colocar unidades feitas para jogadores de videojogos… Vi análises citando 2-3 anos. Que análises, de que modelos? De qualquer maneira, Raid 1 com um estepe deve ser mais do que suficiente mesmo que dure apenas dois anos. O ganho de desempenho vale a pena, geralemente, para tão poucos dados. Fiquei meio receoso quanto a isso. Algué utiliza em servidor? Muita gente. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Quais discos usar ?
2015-07-30 16:02 GMT-03:00 Rodrigo Della Justina rodrigodellajust...@gmail.com: Uma outra estratégia também é pensar que nesse Data Warehouse, nem todos os dados precisam ser armazenados em discos com alta capacidade de leitura Creio que nem vale a pena considerar isso. Com apenas 200 GB de dados, três unidades SSD em Raid 1 com estepe já dá e sobra, e o custo é bastante razoável. Eu diria que nem vale a pena pensar em fazer algo mais complicado; o tempo de pensar a respeito já vai custar mais caro que qualquer possível economia. A menos que não haja grandes necessidades de desempenho, caso em que valeria a pena um Raid 1 de discos rígidos com estepe, mesmo. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Quais discos usar ?
2015-07-30 12:33 GMT-03:00 Raphael Coutinho raphael.couti...@dbmax.com.br: Vamos montar um Servidor que vai abrigar a nossa base de produção com aproximadamente 200Gb. Gb ou GB? Estou a estudar que tipo de discos utilizar. Você tem alguma recomendação, a princípio penso em utilizar um misto de discos SAS 15K e SSD para suprir as consultas, já que pelo que li o SSD tem um melhor potencial em leitura. Com tão poucos dados, eu pensaria em fazer um Raid 1 ou 10 só com SSD. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] migração postgresql v 8.2.17 para 9
Em 3 de julho de 2015 10:08, Luiz Henrique luiz.henriqu...@gmail.com escreveu: Estamos analisando a possibilidade de migrar nosso postgresql v 8.2.17 para versão 9. ai veio a dúvida : para qual versão migrar ? 9.1 / 9.2 / 9.3 / 9.4? Sem dúvida, 9.4. Em 1a análise estamos analisando pular logo para 9.4. Aí eu pergunto aos colegas, é prudente ? Sim, claro. Veja que o PostgreSQL não tem defeitos conhecidos, todos são corrigidos imediatamente. A versão 9.4 tem ganhos / melhorias expressivas em relação as anteriores ? Sim, vide notas da versão (/release notes/). -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Instalar o postgresql
Em 26 de junho de 2015 23:36, Antonio Cesar cgcesarsoa...@gmail.com escreveu: Pessoal estou tentando instalar o postgresql e retorna o seguinte erro A rigor, esse é um problema não de PostgreSQL, mas de configuração do apt no teu Debian. Os pacotes a seguir têm dependências desencontradas: postgresql-9.4 : Depende: postgresql-client-9.4 mas não será instalado Depende: postgresql-common (= 142~) mas não é instalável Depende: ssl-cert mas não é instalável E: Impossível corrigir problemas, você manteve (hold) pacotes quebrados. Informe os resultados de: aptitude versions postgresql- aptitude versions ssl-cert aptitude show postgresql-9.4 -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Quantidade de campos na chave primária
Em 24 de junho de 2015 13:50, Márcio A. Sepp mar...@zyontecnologia.com.br escreveu: Estou modelando uma base de dados onde em alguns casos eu tenho até 12 campos na chave primária. Normal, independente da chave ser primária ou alternativa. Estas tabelas ficam na borda da modelagem, ou seja, são tabelas de movimentação as quais recebem um número maior de registros. Sem problemas. Gostaria da opinião dos colegas se isso pode significar algum problema pra mim no futuro. (desempenho, espaço... etc). Não. Poderiam gerar problemas, eventualmente, se fossem relações pai (referenciadas) com filhas (referenciadoras) muito grandes. Nesses casos, você poderia definir chaves alternativas artificiais para uso nas restrições de integridade referencial das relações filhas que apontam para as pai. Mas, como você não deve definir chaves artificiais sem preservar o menos uma das chaves naturais de cada relação, isso representaria economia somente nas filhas, não nas pai, que pelo contrário engordariam de um índice, o que pode até vir a ser contraproducente. Acho que ficou um pouco confusa minha explicação, ou deu para o gasto? -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] RES: Quantidade de campos na chave primária
Em 24 de junho de 2015 16:02, Márcio A. Sepp mar...@zyontecnologia.com.br escreveu: Deu pro gasto! Rsss Muito obrigado! De nada. Só pra te falar, minhas tabelas são +/- assim: Tabela1 * pk_tab1 Tabela2 * pk_tab1 * pk_tab2 Tabela3 * pk_tab1 * pk_tab2 * pk_tab3 ... Tabela6 * pk_tab1 ... ... * pk_tab12 Na prática... lá pelo 6 nível, eu tenho uma tabela com 12 campos na chave. Todos os relacionamentos estão em cascade. O que me assustou é a quantidade de campos na chave primária e os impactos disso no banco de dados... Acaso tens alguma medição do desempenho de um banco escrito desta forma? Ah, agora entendi. Antes havia entendido que só no último nível você tinha essas chaves grandes. Eu não tenho medição, nunca fiz algo desse tamanho. Mas lembre-se que otimização precoce é a raiz de toda sorte de males: se essa modelagem é a conceitualmente mais adequada, implante assim, e se constatar problemas para a frente acrescente as chaves artificiais. É muito mais complicado definir com chaves artificiais e tentar converter para naturais depois que teus dados já estão inconsistentes por falta de chaves naturais. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Vacuum e Vacuum Full
Em 19 de junho de 2015 09:46, Franklin Anderson de Oliveira Souza frankli...@gmail.com escreveu: Olá @Guimarães, estou usando a versão 9.3 rodando numa maquina CentOS. Executo via script shell agendado no crontab manutenções diárias de vacuum e analyse e somente finais de semana faço um vacuum full. Não executo autovacuum. Então, recomendo deixar o autovacuum fazer seu trabalho. Somente deixe de usar o automatismo da manutenção do PostgreSQL quando você tiver uma razão precisa para isso, especificamente uma situação fora do comum em que o automatismo não lhe atende. Como você não tem clareza sobre as conseqüências de sua rotina de limpeza, melhor abandoná-la e deixar o autovacuum trabalhar, ao menos até que você pesquise mais sobre a adequação de uma rotina personalizada para tua situação específica. Resumindo: se você não souber explicar, técnica e especificamente na tua situação, porque tem uma rotina própria em vez de autovacuum, melhor abandonar sua rotina e habilitar o autovacuum. Preferencialmente em seguida a uma limpeza completa. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Vacuum e Vacuum Full
Em 19 de junho de 2015 09:37, Franklin Anderson de Oliveira Souza frankli...@gmail.com escreveu: A um tempo parei de realizar vacuum full no banco que tem aproximadamente 50 gigas devido a falta de espaço. Depois disso tenho reparado que o simples vacuum tem demorado cada vez mais. Isso é previsivel ?! A falta de um vacuum mais completo pode demorar cada vez mais o tempo para realizar um vacuum mais simples !? Antes de entrar nos detalhes, que versão você usa? Você deixa o PostgreSQL realizar as limpezas automáticas com o autovacuum? -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Solução ansi para isso
Em 27 de maio de 2015 20:18, Matheus Saraiva matheus.sara...@gmail.com escreveu: bem tenho a seguinte inserção: A Ansi saiu da padronização SQL faz muito tempo, que eu saiba. Como os padrões atuais são ISO, tua linha de assunto até me confundiu! :-) -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Instalação do postgres em windows
Em 15 de maio de 2015 11:06, Danilo Silva danilo.dsg.go...@gmail.com escreveu: Estou tentando instalar a versão 9.3.6 em windows server 2008 Meus pêsames. Pelo MS Windows, porque o PostgreSQL funciona até nessa joça. porém, logo no início dá erro de Microsoft VC++ runtime installer. Qual erro exatamente? Alguém já passou por esse erro? Dependendo da mensagem, provavelmente sim. Alguma dica? Instalar o MS VC++ runtime? -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Instalação do postgres em windows
Em 15 de maio de 2015 11:25, Danilo Silva danilo.dsg.go...@gmail.com escreveu: An error ocoured executing the Microsoft VC++ runtime installer Que tal instalá-lo à parte, então? -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Jobs
Em 15 de maio de 2015 16:08, Matheus Ferreira mferre...@bklogistica.com.br escreveu: Gostaria de saber como ativar o job no postgres 9.3 pgAdimin Como assim? Que tarefa? -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] FATAL incorrect checksum in control file - restaurar em outro linux
Em 11 de maio de 2015 09:23, Moisés P. Sena moisesps...@gmail.com escreveu: Em 7 de maio de 2015 10:31, Guimarães Faria Corcete DUTRA, Leandro Por que não usar o binário do Debian AMD64? Porque os binarios atualizam sempre, para o que faço nao tem necessidade. Uso o basico do PostgreSQL, o SO atualiza e eu mantenho o meu Postgres inalterado. Se você usa mais antigo que os pacotes binários do Debian, não corre o risco de ficar sem suporte? Muito obrigo a todos!!! De nada! -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] FATAL incorrect checksum in control file - restaurar em outro linux
Em 7 de maio de 2015 09:44, Moisés P. Sena moisesps...@gmail.com escreveu: Meu servidor de banco de dados deu problema no HD, ficava dando erro de IO, era Ubuntu 14.04LTS amd64. Copiei o diretorio DATA do postgres para outro linux, Debian 7.5 i386 Por que i386? Não é compatível com os dados AMD64. compilei os mesmos fontes Por que não usar o binário do Debian AMD64? Segundo li na net, é pq mudou o SO e arctetura. Só arquitetura, o SO é irrelevante. De qualquer forma, gostaria de rodar o mesmo no SO atual. Sem problemas, desde que seja na mesma arquitetura. Tem como eu restaurar o DATA sem reinstalar o Ubuntu? Tem, instale o Debian AMD64. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Acesso base
Por favor, evite mensagens formatadas, prefira texto simples e siga a RFC 1855 e correlatas. Tua mensagem ficou confusa com os erros de formatação. Em 7 de maio de 2015 18:00, Walison Jose de deus walison.joseded...@gmail.com escreveu: Erro ao estabelecer conexão com o Banco de Dados. Por favor verifique se o mesmo está ativo e acessível pelo servidor Biblivre. Siga as instruções. Por exemplo, teste com o usuário do tal servidor se o psql consegue acesso à base. Ocorreu um erro de aplicação durante a execução deste pedido. Os detalhes deste erro não podem ser visualizados a partir de um computador remoto (por medidas de segurança), mas podem ser vistos através de um navegador executado a partir do computador onde o Biblivre está instalado. E qual o resltado deste teste? O servidor está ativo, porque tenho outra base no mesmo servidor e que está acessível e é acessada por outra aplicação. Pode ser um problema de configuração no Postgres? Não vejo como. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Sabem se existe esse livro do Date traduzido?
Em 30 de abril de 2015 15:44, Flávio Silveira f...@terra.com.br escreveu: Sabem me dizer se existe esse livro do Date traduzido? http://www.amazon.com/SQL-Relational-Theory-Write-Accurate/dp/1449316409 Creio que não. Alguém conhece? Já tenho o Introdução a Sistemas de Bancos de Dados. Está aqui na minha frente quase, esperando uma folguinha para ler. Ou eu voltar a trabalhar com SQL. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Livro do Date traduzido?
Em 30 de abril de 2015 23:46, Flávio Silveira f...@terra.com.br escreveu: Boa noite pessoal, Boa noite! Por que a mesma mensagem enviada três vezes seguidas? -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Standby após Implementação restore_command
Em 4 de maio de 2015 13:52, Edson F. Lidorio ed...@openmailbox.org escreveu: Envie esta mensagem ontem e acho que ela não chegou na lista, pois não recebi o retorno. Aparentemente estamos com problemas sérios na lista, acabo de receber mensagens de quatro dias atrás. Dica para facilitar a vida de servidores e filtros antispam: evite mensagens HTML, prefira texto simples. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Partição de índices lotando
Em 5 de maio de 2015 09:44, Deliane Andrade deliane.andr...@gmail.com escreveu: Ressalto que todos os dias às 00:00h é rodado o vacuum full nessa referida base. Por que não a rotina automática de vaccuum? Alguém teria uma idéia do que estaria gerando isso? Não sem mais detalhes. Interrogue o catálogo sobre quais os objetos maiores na tua partição, veja se a reindexação deles teve sucesso. Geralmente nem seria necessário reindexar, o que parece indicar que tua tentativa de fazer manutenção manual (vaccuum full diário, p. ex.) deixou passar algo importante. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Atualizar dados diariamente em uma base de dados
Em 5 de maio de 2015 09:52, Marcio Ribeiro de Oliveira marcio.olive...@ifro.edu.br escreveu: Bom Dia, estou com a seguinte demanda aqui no trabalho, preciso atualizar diariamente uma base de dados postgreSQL com os dados de uma base em produção, tipo, banco B receber os dados do banco A toda 00h, qual a melhor forma que vocês recomendam ? Banco em Produção PSQL 8.4.21 Linux Debian banco com 2G Banco a ser atualizado diariamente PSQL 9.3.5 Linux Debian Como são versões diferentes, um dump deve resolver. Por favor evite HTML nas mensagens. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] select para retornar DIA da semana em portugues
Em 5 de maio de 2015 12:01, Luiz Henrique luiz.henriqu...@gmail.com escreveu: Preciso de uma função que retorne o DIA da semana em portugues. Encontrei a solução da seguinte forma : select to_char(date'2015-05-05','TMDay') as dia; dia - Tuesday (1 row) E quais as configurações de local da base e do psql? -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] PG_Basebackup não gera timeline history
2015-05-05 9:52 GMT-03:00 André Ormenese aormen...@gmail.com: Quando tento subir o banco em outro servidor Exatamente como? -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] RES: Estrutura do Postgres orientado a objetos
Em 29 de abril de 2015 09:28, Márcio A. Sepp mar...@zyontecnologia.com.br escreveu: Deixa ver se entendi direito. Vou criar abaixo uma sequencia de tabelas utilizando chaves naturais e farei a ligação das tabelas de cadastro com uma tabela de pedido por exemplo. CREATE TABLE public.pais ( codigo integer, nome character varying(50) NOT NULL, PRIMARY KEY (codigo) ); // o código do país é obtido em catálogos internacionais de países (acho que o FEBRABAN o outro órgão disponibiliza). Então é um código associado a estas lista. Essa é uma possibilidade. Outra é usar o código ISO. Vai depender de tua situação, mas o ISO tem a vantagem de ser legível (BR para Brasil, por exemplo) e já atender algumas necessidades de usuário, evitando junções. Só vi esse código numérico sendo usado em ambiente bancário (financeiro), mas creio que deva ter outros usos também. CREATE TABLE public.uf ( codpais integer NOT NULL, coduf integer NOT NULL, sigla character(2) NOT NULL, descricao character varying(50) NOT NULL, PRIMARY KEY (codpais, coduf), FOREIGN KEY (codpais) REFERENCES pais (codigo) ON UPDATE CASCADE ON DELETE NO ACTION ); // O código da UF tbm é fornecido por algum órgão, no caso o IBGE. O mesmo ocorre com o código da cidade abaixo. Idem, código numérico é uma possibilidade mas a sigla (DF para Distrito Federal, por exemplo) serve perfeitamente para a maior parte dos usos, de novo evitando junções. Veja também que, usando o numérico, sigla ainda é uma chave candidata que vale a pena declarar. Mais uma vez, só vi esse código numérico sendo usado em bancos financeiros, mas creio que tenha outros usos. CREATE TABLE cidade ( codpais integer NOT NULL, coduf integer NOT NULL, codcidade integer NOT NULL, nome character varying(50) NOT NULL, CONSTRAINT cidade_pkey PRIMARY KEY (codpais, coduf, codcidade), CONSTRAINT cidade_codpais_fkey FOREIGN KEY (codpais, coduf) REFERENCES uf (codpais, coduf) MATCH SIMPLE ON UPDATE CASCADE ON DELETE NO ACTION ); Aí, sim, faz perfeito sentido. Você pode até declarar uma ‘chave’ artificial se tiver reais (não imaginados) problemas de desempenho para usar como primária, mas não pode deixar de declarar essa chave natural mesmo que como UNIQUE. Só que, como explanado acima, para um caso geral (sem requisitos em contrário) eu preferiria usar as siglas ISO para país e UF. […] CREATE TABLE public.pedido ( codpedido serial NOT NULL, codpais integer NOT NULL, coduf integer NOT NULL, codcidade integer NOT NULL, bairro character varying(50) NOT NULL, rua character varying(50) NOT NULL, numero integer, PRIMARY KEY (codpedido), FOREIGN KEY (codpais, coduf, codcidade, bairro, rua) REFERENCES rua (codpais, coduf, codcidade, bairro, rua) ON UPDATE CASCADE ON DELETE NO ACTION ); Se esta tabela de pedido tiver, digamos que 10.000 pedidos/dia. Qual o inchaço que irá representar criando-a desta forma? Isso você calcula facilmente. Mas não é inchaço, é uma informação útil que evitará muitas junções e atualizações de índice (toda atualização de índice é duplicada quando se usa ‘chave’ artificial: uma vez na chave natural, outra na artificial). Não seria menos custoso criar uma chave artificial na tabela rua para ligar com a tabela de pedido? Não, no caso geral. Sim, se você tiver pouquiíssimo espaço em disco e puder esperar por todas as junções. Na dúvida, ou teste, ou evite a otimização precoce até constatar a necessidade real. E aí teste para ver se a perda de desempenho será aceitável. Em contrapartida, digamos que é imprescindível que o banco de dados forneça a informação de quanto foi feito de pedido por rua, bairro, cidade, uf e país. Mensagem truncada, ou meu cérebro ainda não acordou? -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Estrutura do Postgres orientado a objetos
Em 28 de abril de 2015 20:29, Matheus Saraiva matheus.sara...@gmail.com escreveu: Pois é, vejo que, em parte, eu meio que entendia errado essa critica às chaves artificiais. Hoje mesmo quando enviei a primeira pergunta eu me referia ao uso de chaves naturais compostas em relacionamentos, ou seja, como chaves primárias. Sim, seria o ideal, pelo menos na ausência de separação de modelos lógico e físico. Eu me refira justamente a uma modelagem sem chaves artificiais, onde os campos que compunham as chaves primárias são replicados nas outras tabelas. E é o que eu dizia que geralmente não é problema algum. Esse tipo de modelagem acredito ser complicado em requisitos de hardware limitados principalmente por alguma restrição de armazenamento. É essa crença que se constitui em (falsa) otimização precoce, que como todos sabemos é raiz de toda sorte de males. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Estrutura do Postgres orientado a objetos
Em 28 de abril de 2015 20:05, Matheus Saraiva matheus.sara...@gmail.com escreveu: E se o servidor for modesto? Se o espaço de armazenamento for um requisito crítico? Tire a artificial, se for o caso. Mas lembre-se da máxima: otimização precoce é raiz de toda sorte de males. Quanto ao desempenho de JOINS realmente nuca testei, mas acho que quanto a espaço em disco ao usar chaves naturais compostas para relacionamento é algo inevitavelmente mais custoso, já que teria-se que replicar os mesmo campos que compõe a chave primária na tabela que se relacionaria com ela. Isso só no caso em que a chave primária realmente é ‘replicada’ como chave estrangeira em outras relações. Não é nem de longe o caso geral. Acho que para esse caso, eu usaria chaves artificiais para o relacionamento e criaria UNIQUEs para garantir a unicidade. É uma alternativa válida, quando necessário. Como sempre digo, o pior problema das ‘chaves’ artificiais é quando se confia nelas a ponto de não se declararem chaves naturais. Mas, entre você ter de ter um atributo e um índice extra em uma tabela que pode ser bastante usada, e fazer junções que seriam desnecessárias sem o uso de ‘chaves’ artificiais, geralmente o que se tem é perda de desempenho com as ‘chaves’ artificiais. Na prática, um sistema com chaves naturais é tão diferente de um com ‘chaves’ artificiais, que nunca se fazem testes realistas de comparação. A regra de evitar otimização precoce levaria a fazer um sistema só com as chaves naturais, e só acrescentar as artificiais quando se constantar algum problema real de capacidade ou de desempenho. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Estrutura do Postgres orientado a objetos
Em 28 de abril de 2015 17:30, Matheus Saraiva matheus.sara...@gmail.com escreveu: Já vi muita gente criticando as chaves artificiais e aconselhando o uso de chaves naturais simples ou mesmo compostas. São duas questões separadas. Não é possível criticar as chaves artificiais, assim como não é possível criticar, digamos, o oceano Atlântico. São um fato da vida. O que se critica é o abuso delas. Chaves artificiais foram primeiro imaginadas como um recurso para os DBAs implementarem por debaixo dos panos, como equivalentes a uma chave natural composta ou, por algum outro motivo, relativamente ineficiente. Não era para ser visível no modelo lógico de dados, e portanto nem aplicações, nem usuários a veriam. Entretanto, infelizmente o SQL — ou, pelo menos, suas atuais implementações — não permite separar direito os modelos lógico e físico; assim, começou-se a criar chaves artificiais como complementos visíveis, em vez de como implementações invisíveis, de chaves naturais. Até aí, o pressuposto seria que, além de uma chave artificial, sempre haveria ao menos uma chave natural em cada relação (‘tabela’). O problema é que hoje em dia a maior parte dos usuários nem se preocupa em definir uma chave natural por relação que seja. Isso leva a vários problemas, dos quais o mais imediato é a possibilidade de duplicação de dados, e o mais importante é o desconhecimento do próprio modelo de dados (do qual ao menos uma chave natural por relação é parte essencial). Outra maneira de ver a coisa: uma chave artificial não é uma chave de verdade, a menos que corresponda a uma chave natural declarada, implementada e operante, uma vez que não cumpre a função básica de uma chave, que é garantir unicidade. Em inglês, isso fica claro no nome /surrogate/, que é um substituto, um procurador; será que seria o caso de pararmos de as chamarmos de ‘artificiais’ e usarmos algo mais próximo de uma tradução de /surrogate/, como ‘substituto’ ou ‘complementar’? Não sei qual seria uma tradução que restringisse a interpretação à original; talvez ‘por procuração’? Uma chave natural composta de (email, cnpj, nome). Isso não causaria redundâncias de dados, aumentaria o consumo de espaço em disco e prejudicaria o desempenho? Não, isso evita duplicidade e é essencial. A chave artificial é que, por definição, é redundante (desnecessária); e a falta de declaração duma chave natural leva a validações em aplicação, que geralmente são piores que as feitas pelo SGBD. Visto que é mais leve e performático gravar, duplicar e fazer transações com um INTEGER do que em um conjunto de três VARCHAR? Não necessariamente. Você já conduziu os testes comparando? Já verificou o contraste entre usar uma chave natural e a validação em aplicação? Já verificou quantas junções o uso de chaves naturais evita? E os custos decorrentes de manutenção necessária pela má compreensão do modelo ao longo da vida útil da base? Geralmente, a disciplina de definir chaves naturais em cada relação ajuda a normalizar a base, tornando o sistema como um todo mais leve, mais lógico e mais robusto. Mesmo que num caso ou noutro tenha de se complementar as chaves naturais com uma ou outra artificial. E se o servidor for modesto? Se o espaço de armazenamento for um requisito crítico? Tire a artificial, se for o caso. Mas lembre-se da máxima: otimização precoce é raiz de toda sorte de males. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Estrutura do Postgres orientado a objetos
2015-04-28 11:34 GMT-03:00 Irineu iri...@senda.inf.br: Estou modelando o banco de dados(Postgres off course) de uma aplicação em java web para loja. /Of [ov] course/. /Off [of] course/ significa fora da corrida, ou algo assim. Fiz uns testes criando types para os objetos como segue exemplo abaixo. Ιsso te traz alguma vantagem para a aplicação? CREATE TYPE cliente AS (nome character varying(250), cnpj_cpf character varying(20), email character varying(250); CREATE TABLE tb_cliente (id SERIAL PRIMARY KEY NOT NULL, cliente CLIENTE); Faltou chave. Lembre-se que a chave artificial (id) não substitui a natural, embora possa, em algumas situações, complementá-la, uma vez que não garante a unicidade. No teu modelo, eu diria que chaves candidatas seriam (nome, cnpj_cpf), (nome, email), ou mesmo (nome, cnpj_cpf, email). A estimativa de crescimento do banco é atingir no máximo 20GB. Normal. Dentro desse cenário posso ter problemas de desempenho Dificilmente. ou seria melhor modelar da forma tradicional ? A menos que você tenha ganhos na aplicação, ou reusará ‘cliente’ noutras relações (tabelas), seria melhor modelar sem o TYPE porque ele acaba complicando o modelo, tornando-o mais opaco principalmente para quem não participou da modelagem. Mesmo você, se a aplicação alcançar alguma estabilidade a ponto de não precisares te preocupar dela por uns meses, verá depois de um ano ou algo assim que não ficou tão transparente quanto poderia. Lembre-se que se continua falando do PostgreSQL como ‘objeto-relacional’ mais por uma questão de publicidade; o que no PostgreSQL (ou em qualquer SGBD) realmente facilita orientação a objeto é a riqueza de tipos e a conformidade ao modelo relacional, não exatamente TYPEs ou herança. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] embeber código SQL ou PL/SQL em Latex?
2015-04-28 11:28 GMT-03:00 Eloi e...@openmailbox.org: Estou a escrever documentação de uma base de dados em Latex e gostaria de, no anexo da documentação, listar todas as tabelas da base de dados mais detalhes (como por exemplo: as colunas que contem, ,comentário, gatilhos, constraints). Pergunta: É possível fazer isso embebendo código SQL ou PL/SQL no documento Latex? Obrigado. Não sei se entendi a pergunta, visto que ela me pareceu bem trivial. Mas, se entendi, sim, o LaΤεχ tem um módulo de linguagens de programação que leva em conta SQL na formatação. Dá para fazer mais, programação literária (/literate programming/). Tem uma palestra antiga minha http://dutra.fastmail.fm/PostgreSQL/adpg.art.pdf em que expliquei como o fazia. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Analyze e Vaccum consomem espaço ?!
Por favor, evite responder no topo e em HTML. 2015-04-23 14:58 GMT-03:00 Franklin Anderson de Oliveira Souza frankli...@gmail.com: Exatamente amigos ! essa mensagem só acontece nos finais de semana quando e executo o vacuum full !! Prefira seguir a indicação do Gurgel: De qualquer forma, porque não utilisar apenas o autovacuum corretamente ajustado? Isso evitaria um crescimento exagerado do tamanho do banco de dados em disco e evitaria a dor de cabeça das operações noturnas. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Ferramenta de modelagem com bom recurso para criar funções
2015-04-18 21:50 GMT-03:00 Matheus Saraiva matheus.sara...@gmail.com: Um editor de textos decente, com o SQL::Fairy ou o pgAutoDoc. Entendo... Criar as tabelas e suas restrições e relacionamentos é até tranquilo, mas acho que na hora de se criar outros elementos ficaria meio complicado. Tipo, geralmente na hora de criar uma função, uma view, ou qualquer coisa que você criar após as tabelas estarem prontas, fica complicado se você precisar de algumas informações da qual você não lembra de pronto, tipo, qual o tipo de dado você definiu para um campo X na tabela Y. Uai, qualquer editor decente faz isso, principalmente se tiver um modo tipo IDE. Se esse IDE tiver interface com a base de dados, então… Procurar essa informação em um arquivo de. sei la. 700 linhas de código é osso. No diagrama você teria uma representação gráfica de tudo, ficando muito mais fácil encontrar. Por mais que o editor tenha recursos para localizar palavras através de regex, acho que ainda não seria tão prático quanto. Pelo contrário, um bom editor torna isso muito mais fácil que um diagrama. Diagrama só é prático para modelos muito simples e pequenos, que dificilmente se encontram na prática. Acho que teu problema não é falta de ferramental, é nuca ter visto alguém usar um ferramental legal, como a combinação do SQL Mode do GNU Emacs com LaTeX, Literate programming (p. ex., noWeb) e pgAutoDoc. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] SELECT FOR UPDATE tentando obter lock
Por favor corte o que não é relevante à sua resposta, facilita quem vai responder. 2015-04-15 13:47 GMT-03:00 Rosana de Oliveira rosana.pi...@gmail.com: O nível de isolamento do Postgresql é o read committed. Não sei qual é o do Oracle. O padrão do Oracle me parece ser o mesmo. Esqueçam-no. Por quê? Às vezes é mais fácil lembrar dos níveis de isolamento comparando o comportamento que direto dos conceitos. Uma resposta da literatura formal (Date, Navathe, Silberchatz) para mim, seria suficiente. Claro. Só não está fresco na minha mente, e não posso parar para relembrar aqui. Tenha um pouco de paciência, normalmente esse tipo de pergunta é respondido na lista no mesmo dia, talvez no seguinte. Só para explicar, o cenário que coloquei foi totalmente didático. Nem precisava explicar isso, até pelas relações extremamente simples e sem chaves naturais. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] SELECT FOR UPDATE tentando obter lock
Por favor, evite mensagens HTML. Ler código em Comic Sans não é muito agradável… 2015-04-15 13:16 GMT-03:00 Rosana de Oliveira rosana.pi...@gmail.com: 2. Só de curiosidade, fizemos o mesmo teste no Oracle e não ocorreu erro algum. Quais os respectivos níveis de isolamento? -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Upgrade Postgis
2015-04-02 11:43 GMT-03:00 Leandro leandr...@gmail.com: Pessoal, alguem que manja bem de postgis poderia me dar um help ... Por favor, se possível, texto simples, não HTML. Está ruim de ler. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] archive_command
2015-04-02 7:42 GMT-03:00 Fernando Cambiaghi cambia...@gmail.com: Vejam as imagens abaixo, uma é a pasta pg_xlog do banco e a outra é o destino de archive_command Por favor, não envie imagens a menos que seja último caso. Prefira a listagem textual, numa mensagem de texto simples (não HTML). -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Servidor de banco de dados
2015-04-01 13:05 GMT-03:00 Carlos Antônio Pereira (VidaUTI) carlosanto...@utivida.com.br: Alguém poderia me indicar uma marca de servidor (além da Dell)? Entre as grandes marcas, HP costumava ter o melhor suporte a Debian, que me lembre, que é sempre uma boa pedida como plataforma para o PostgreSQL. E é sinal dos tempos que Dell tenha vindo antes de IBM, mesmo que hoje ela tenha apenas Risc — mas os x86 e AMD64 ainda estão disponíveis pela Lenovo. Não sei se a Itautec continua no mercado, antigamente ela vendia os sistemas de referência da Intel. A Sun também continua com o nome Oracle, mas seria meio contrassensual dar dinheiro a nosso principal concorrente. No campo Risc e S/360, não sei se os japoneses continuam: Fujitsu, Hitachi… Os colegas poderiam informar se a Bull ainda vende equipamento; se vender, é uma empresa que tem empregado colegas da comunidade, que me lembre. De cabeça, é isso. Creio que o Google poderia ajudar também. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Servidor de banco de dados
2015-04-01 15:12 GMT-03:00 Fábio Telles Rodriguez fabio.tel...@gmail.com: A Bull foi comprada pela Atos e está mudando seu foco atualmente. Sim ainda vende equipamentos. Sei que é meio sacanagem perguntar, então fique à vontade de não responder, mas isso significa que deixará de vendê-los, ou de suportar o PostgreSQL? Eu chutaria as respostas sim e não, respectivamente… -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] CA APM usa PostgreSQL
De um colega fazendo um curso: ‘Essa solução é divida em dois módulos, Intrascope e CEM. Fica evidente que são dois sistemas distintos, que a CA comprou e uniu em um Frankstein. ‘O interessante é que o CEM usa um banco Postgre. Isso já está instalado na infraestrutura do Cenin. Logo, pode-se dizer que o Cenin já usa Postgre.’ -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] RES: RES: RES: Segurança dos dados
Por favor evite responder em HTML, ficou confuso. Siga o modelo de quem responde em texto simples, com marcadores ‘’ à esquerda e cabeçalho de citação: 2015-03-27 12:11 GMT-03:00 Márcio A. Sepp mar...@zyontecnologia.com.br: Não seria mais fácil embutir essa função no código do sistema ao invés de fazer em PL? Assim a preocupação com segurança de código fica só no lado da aplicação e menos no banco de dados. Segurança de código é meio ilusória, sempre dá para descompilar. E há todos os problemas conhecidos, não apenas de desempenho mas principalmente de consistência. Integridade em aplicação é quase garantia de que mais cedo ou mais tarde a base ficará inconsistente. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] RES: Segurança dos dados
2015-03-26 9:32 GMT-03:00 Márcio A. Sepp mar...@zyontecnologia.com.br: Acho interessante... mas não sei se o postgresql tem algo neste sentido. Por favor, leiam as mensagens anteriores antes de responder. Não tem, e a comunidade não quer que tenha, portanto não deve vir a ter. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] RES: RES: Segurança dos dados
2015-03-26 11:43 GMT-03:00 Márcio A. Sepp mar...@zyontecnologia.com.br: Teve um caso de desenvolvimento de sistemas comerciais onde o fisco pegou clientes utilizando o mesmo sistema, porém com comportamentos bem distintos. Neste caso específico, a pessoa que foi implantar o sistema alterou funções do sistema de modo a permitir um caixa 2. Este sistema era desenvolvido em Firebird e depois desse fato, a empresa desenvolvedora optou por ocultar o código fonte dos procedimentos do banco... Até achei esse um caso de uso interessante; me pergunto qual seria a reação se apresentado na -hackers. Imagino que algo assim já tenha pipocado por lá. Mas, como disse o Euler (se não me falha a memória), isso é um problema essencialmente contratual: nenhuma empresa é responsável pelo uso que fazem dos programas dela, e em caso de preocupação basta uma cláusula contratual deixando isso claro. Talvez não seja sábio alterar o PostgreSQL para dar conta disso. Me pergunto também se seria algo que pudesse virar um contrib da vida. Daria para fazer também coisas como um programa que verificasse a integridade do código antes de rodar, por exemplo. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Timeout Conexão
2015-03-26 10:07 GMT-03:00 Julio F. Figueiredo tuski...@gmail.com: Vê nas configurações de energia se o windows não desliga a placa de rede depois de um tempo inativo. Por favor, evite tanto responder no alto como escrever em HTML. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Segurança dos dados
2015-03-25 18:13 GMT-03:00 Danilo Silva danilo.dsg.go...@gmail.com: Existe alguma maneira de bloquear a visualização das functions e o seu conteúdo? Além do que o Telles já apontou muito propriamente, veja que isso seria apenas um /trade secret/, que goza de alguma proteção legal mas muito frágil, somente até o momento que deixar de ser segredo. E sempre daria para decompilar, como aliás se faz em outros SGBDs. O que realmente resguarda seus direitos é a legislação em vigor, sobre direitos patrimoniais do autor. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] bigint e bigserial, quando usar?
2015-03-24 10:38 GMT-03:00 Matheus Saraiva matheus.sara...@gmail.com: Aproveitando esse tema, alguém aqui na comunidade já atingiu o limite do integer com chaves artificiais? O que acontece e o que fazer? Não é uma resposta à tua pergunta, mas acabo de pensar que, com chaves naturais, isso não aconteceria salvo erro de modelagem. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] bigint e bigserial, quando usar?
2015-03-24 13:39 GMT-03:00 Matheus Silva matheus.sara...@gmail.com: O email apesar de único não pode ser obrigatório. Uma imagem nunca dará todas as informações, do tipo ‘por que não pode?’. De qualquer maneira, parece um modelo muito ruim esse, mas aqui não é o lugar para explorar todos os problemas potenciais. Como eu disse, em último caso uma chave única com todos os atributos não artificiais. Mas pense pelo outro lado: se não houver uma chave natural (mesmo que composta e não a primária), como evitar a duplicação de dados? Se houver alguma lógica de programa aplicativo que evita duplicações, essa lógica deve ser analisada e implementada declarativamente como uma restrição de integridade, que nada mais é que uma chave natural, seja composta ou simples, seja primária ou alternativa. Pessoalmente eu acho que não se pode generalizar tal coisa, cada caso é um caso. Ciência se faz com generalizações, também chamadas de teorias. Se houver alguma exceção relevante, expande-se a teoria para dar conta da exceção. Não há espaço na Informática para ‘pessoalmentes’; todos esses ‘achos’ devem ser analisados, criticados, e ou formalizados na forma de conceitos, ou rejeitados. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] bigint e bigserial, quando usar?
2015-03-24 13:55 GMT-03:00 Matheus Silva matheus.sara...@gmail.com: Desculpe Brother mas não concordo com você, não vou aqui entrar no mérito para não desviar o foco do email. Você pode apresentar as desvantagens da minha modelagem e eu posso enumerar as vantagens, bem como as desvantagens da sua proposta, convém a que preparou a modelagem pesar os prós e contras para o caso. Claro. Como eu havia dito, lista de discussões não é o lugar para debater modelos específicos, só conceitos e suas aplicações. Mas veja que você não conseguiu analisar a questão da duplicidade que eu propus, que é a essência do conceito de chave, e de que as ‘chaves’ artificiais não dão conta. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Sistema financeiro em PostgreSQL
2015-03-20 10:37 GMT-03:00 Carlos Antônio Pereira (VidaUTI) carlosanto...@utivida.com.br: Alguém conhece algum Sistema Financeiro (Contas a pagar e receber, etc) que use o PostgreSQL como base de dados? Há vários (PostBooks, xTuple, Adempière…). Alguns estão localizados e contam com prestadores de suporte locais. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como fazer esse select no postgresql?
2015-03-17 11:45 GMT-03:00 Vinicius Santos vinicius.santos.li...@gmail.com: Em 17 de março de 2015 11:36, Douglas Listas douglas.gru...@gmail.com escreveu: select cpf_comprador, list(distinct nome_comprador), sum(vlr) from vendas group by cpf_comprador; Roda em um banco Sybase (Watcom)... Substitua list por string_agg[1]. Havia projetos para implementar funções de outros SGBDs: Oracle, MySQL, SQL Server… o MS SQL Server é baseado no Sybase, se não me falha a memória. Talvez seja uma boa verificar, caso haja muitos usos de funções a substituir. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Uso de índice x Seq scan - Tabelas pequenas
2015-03-13 11:56 GMT-03:00 Luiz Carlos L. Nogueira Jr. lcnogueir...@gmail.com: Sim (ANALYZE), mas por que pegou o índice ao invés da tabela? Não entendi a escolha. Algumas tabelas são tão pequenas que vale a pena ignorar o índice; mas se a consulta pode ser satisfeita somente com os dados do índice, nem vale a pena olhar a tabela. Não sei se é o caso especificamente. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] [pgbr-dev] Digest pgbr-dev, volume 99, assunto 6
Devolvendo para a lista de usuários. 2015-03-12 10:10 GMT-03:00 Alvaro Herrera alvhe...@alvh.no-ip.org: Hay otras razones para no usar herencia. Por ejemplo, las restricciones UNIQUE no funcionan. (Las restricciones UNIQUE se implementan internamente con un índice btree UNIQUE, pero en Postgres no existen índices cubran más de una tabla. Como la tabla heredada es una tabla separada de su tabla padre, el UNIQUE no funciona). Este es precisamente el problema que describe quien hizo la pregunta inicial. Só traduzindo, que acho que vale a pena: Há outras razões para não usar herança. Por exemplo, as restrições UNIQUE não funcionam. Elas são implementadas com um índice de árvore b, mas no PostgreSQL não há índices que cubram mais de uma relação. Como uma relação herdada é separada da relação mãe, o UNIQUE não funciona. Esse é precisamente o problema descrito por quem fez a pergunta inicial. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Consulta não está utilizando índice
2015-03-05 13:10 GMT-03:00 Fernando Cambiaghi cambia...@gmail.com: No mínimo, declare CPF e CNPJ como chaves também. Temos apenas um campo para estes dois, chamado nr_cpf_cgc( varchar(14) ), sendo que é um índice único com validação para CPF e CNPJ na inclusão. Exatamente o que sugeri, parabéns. Assim dá para respirar e esperar o momento de normalizar. Você poderia até usar isso como chave primária (e estrangeira nas ‘filhas’), o que tornaria essa tabela menor, economizaria um índice e suas atualizações, e talvez evitasse algumas junções. Mas o mais urgente já fizeste. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] PostgreSQL e NFS
2015-03-05 13:29 GMT-03:00 Émerson Eng. emersonnar...@gmail.com: Infelizmente não posso instalar aplicações no servidor de storage. Tenho apenas uma pasta acessível via NFS e, um usuário via SSH sem permissão root ou de instalar qualquer coisa, ou mesmo abrir qualquer portas. Não espere desempenho ou confiabilidade extremas. É administrável, mas implica latência e acrescenta ponto de falha. Mesmo virtualização costuma acrescentar latência e pontos de falha. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Consulta não está utilizando índice
2015-03-05 12:55 GMT-03:00 Fernando Cambiaghi cambia...@gmail.com: cd_cliente é uma chave primária? Qual é o esquema da tabela cliente? Sim, cd_cliente é a chave primária. Essa é uma tabela que foi criada em nosso sistema em 1998 e não está normalizada como deveria, mas acho que nem vem ao caso. Essa tabela armazena clientes PF e PJ, por isso a PK não é o CPF do cliente. Possivelmente não é viável ou interessante mudar tudo, mas a chave primária poderia, em tese, ser definida sobre um atributo ‘CPF/CNPJ’, com restrições de integridade tanto para validar CPF ou CNPJ quanto para, na dificuldade de normalizar, garantir que outros atributos estão consistentes com o CPF/CNPJ. No mínimo, declare CPF e CNPJ como chaves também. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] PostgreSQL e NFS
2015-03-04 17:34 GMT-03:00 Émerson Eng. emersonnar...@gmail.com: Gostaria da opinião especialmente de quem já utilizou NFS(Network File System) junto ao PostgreSQL para dividir a pasta data pela rede. Nunca usei, mas não é necessário provar um ovo para saber que está podre. Eu, particularmente, gosto muito do NFS. Mas não é o caso de introduzir um ponto de falha desnecessariamente. Não só ponto de falha como latência também. Se você tem discos numa máquina e o PostgreSQL na outra, considere mover ou os discos ou o PostgreSQL. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] PostgreSQL e NFS
2015-03-05 12:49 GMT-03:00 Flavio Henrique Araque Gurgel fha...@gmail.com: Como é que se chamava isso, ‘problema A-B’? Onde a pessoa pergunta o que quer fazer, mas não explica sua real necessidade? Problema XY - Você quer fazer X, acha que Y é uma boa solução e pergunta como fazer Y. Merci ! -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] PostgreSQL e NFS
2015-03-05 12:44 GMT-03:00 Flavio Henrique Araque Gurgel fha...@gmail.com: Dividir o diretório do cluster pela rede não faz sentido na maioria dos casos, talvez para algum tipo de failover, explique melhor sua necessidade. Como é que se chamava isso, ‘problema A-B’? Onde a pessoa pergunta o que quer fazer, mas não explica sua real necessidade? -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] duvida com campo que deferia ser FK
2015-03-03 13:48 GMT-03:00 Douglas Fabiano Specht douglasfabi...@gmail.com: O campo idempresa é alimentado em 50% de 700 tabelas. logo eu deveria de criar esse campo como FK nas 350 tabelas? Por que não? ou crio somente o campo idempresa (int) para armazenar tal informação? O ideal seria uma chave natural, como por exemplo CNPJ. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] OFF - Tirinha VP
2015-02-28 16:43 GMT-03:00 Fabrízio de Royes Mello fabri...@timbira.com.br: On 28-02-2015 11:38, Fabiano Abreu wrote: Hahahahaha... é ilário, mas esses dias em um cliente alguém (nao descobrimos quem) foi lá no $PGDATA/base e removeu alguns diretórios, creio eu que pra liberar espaço em disco visto que o monitoramento havia alertado antes. kk Tive um colega apelidado de ‘gZip’. Quando era SysAdmin novato, os veteranos foram para uma conferência e o deixaram com a senha de superusuário. Ele foi lá e apagou uns arquivos .log… do Oracle. Depois de algumas semanas, aconteceu o mesmo, mas ciente de que não podia apagar arquivos, ele os comprimiu… -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] OFF - Tirinha VP
2015-03-02 15:48 GMT-03:00 Ivo Sestren Junior i...@sestren.com.br: Tinha um que trabalhou comigo que apelidamos de Dãs […] Dãs - Sim, tabela DOES, o erro é TABLE DOES NOT EXIST A gente é ruim! -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] ferramenta para modelagem
2015-02-27 9:49 GMT-03:00 Douglas Fabiano Specht douglasfabi...@gmail.com: alguem utiliza ou conhece alguma ferramenta de modelagem para postgres que possua controle de versao por colaboração? de preferencia Open Não sei exatamente o que é ‘controle de versão por colaboração’ (¿redundância?), mas código fonte é perfeitamente versionável por qualquer ferramenta livre, além de ser a única maneira de fazer um modelo rico, fácil de manter e de ler; e há as ferramentas livres para diagramar como SQL::Fairy ou AutoDoc, entre várias outras — vide, por exemplo, https://stackoverflow.com/questions/3223770/tools-to-generate-database-tables-diagram-with-postgresql/20735140#20735140 -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Ajuda numa modelagem
2015-02-27 14:14 GMT-03:00 Flávio Silveira f...@terra.com.br: Me parece que o e-mail caiu no spam de vocês pois coloquei link com fotos do diagrama. Não seria normal, pelo menos não se vier em texto simples. Primeira pergunta: Qual a forma correta de postar diagramas aqui? No meu caso eu mandei para o imgur e coloquei o link aqui. Parece razoável. Mas a forma preferida é mandar o SQL. Diagramas são, necessariamente, resumos da realidade. O SQL é a realidade, no caso. Certo, sou novato em banco de dados, comecei agora aprendendo modelagem relacional, meu primeiro problema é o seguinte: Meu pai me pediu um sistema simples para controlar financiamentos, saber vencimento, parcelas, juros etc. Não seria melhor usar o GNUCash ou algo até mais simples? O GNUCash inclusive podia gravar os dados em PostgreSQL. Minha primeira ideia foi criar 3 entidades: Empresa (ID, Nome_Empresa), Banco (ID, Nome_Banco), Pessoa (ID, Nome_Pessoa, Tipo). Esses IDs parecem desnecessários. Parece que os nomes são chaves naturais, no caso — embora em casos mais complexos dificilmente sejam. Uma alternativa é substitui-los por CPF/CNPJ. Meu amigo olhou e sugeriu 3 entidades: Empresa (ID, Nome_Empresa, Tipo), Financiamento (Parâmetros de financiamento aqui), Pessoa (ID, Nome_Pessoa, Tipo), sendo que o atributo Tipo na entidade Empresa pode ser B (de Banco) ou E (Empresa). Se os atributos de empresa normal e banco forem os mesmos, não há problema. Mas isso poderá obrigar a consultar frequentemente o tipo de empresa. Sei que faltam detalhes, mas é só uma visão geral: Qual das duas soluções parecem mais corretas? A tua me parece boa. A dele também não está errada. Depende dos detalhes. Mas pense em usar o GNUCash. Se for para operar um negócio, há alternativas mais robustas. Agora me fogem os nomes, mas lembro de xTuple, PostBooks… -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Pegar o ID de um vetor de registros
2015-02-27 12:13 GMT-03:00 Matheus Saraiva matheus.sara...@gmail.com: Sobre as chaves naturais e artificiais, a unicidade não pode ser garantida através de unique keys? Pode e deve, sempre que a chave primária for artificial. Inclusive isso ajudará a perceber quando a chave artificial é dispensável, caso em que a natural deve ser declarada como primária. O caso mais óbvio é quando a chave natural for simples (não composta de dois ou mais atributos). Somente preste atenção que quando a chave primária não for natural, pelo menos uma das chaves alternativas (UNIQUE) naturais tem de ser declarada também NOT NULL. Por favor, configure teu gMail para parar de converter as mensagens em HTML. Siga as RFCs 1855 e similares. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Pegar o ID de um vetor de registros
2015-02-27 12:39 GMT-03:00 Matheus Saraiva matheus.sara...@gmail.com: Também acabo deixando os nomes iguais pois as vezes falta criatividade para pensar em nomes de campos diferentes para tantas tabelas :) Isso é relativamente simples. A prática mais comum é criar uma abreviação para cada entidade (não tabela), e prefixar ou sufixar essa abreviação aos nomes de atributo relevantes. Por exemplo, nome_pes e código_pes, e nome_prod e código_prod. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] ferramenta para modelagem
2015-02-27 10:05 GMT-03:00 Douglas Fabiano Specht douglasfabi...@gmail.com: colaboração me refiro a mais de uma pessoa trabalhando na modelagem, e ambos podendo alterar objetos e poder comitar suas alterações. Código fonte com geração automática de diagramas. Quando mexia com isso, tinha um repositório do qual um script no cron gerava diagramas automaticamente, publicados também automaticamente num servidor HTTP. Como o AutoDoc é trivial de usar, era muito fácil criar novos diagramas, e a modelagem continuava na boa com o código fonte. Não caia na armadilha de igualar modelagem a diagramação. Que me lembre, as ferramentas de diagramação com versionamento e colaboração eram caríssimas, e contraprodutivas. Ninguém merece ficar arrastando caixinhas num programa pesado e lerdo. Quer dizer, conheço quem mereça, mas mantenhamos a civilidade na lista. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Pegar o ID de um vetor de registros
2015-02-27 12:03 GMT-03:00 Matheus Saraiva matheus.sara...@gmail.com: Segue o código http://paste.ubuntu.com/10449853/ Bloqueado para mim. Por favor, no corpo da mensagem, e em texto simples. Nunca mande mensagens HTML aqui para esta lista. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Operação com Triggers
2015-02-26 8:32 GMT-03:00 Emanuel Araújo eac...@gmail.com: Encontrei uma situação que pode ser o problema, estou suspeitando ser dados, pois os campos chaves da tabela são texto e encontrei registros com espaços que podem ser o causador do problema. Ou seja, faltou um CHECK CONSTRAINT para assegurar a qualidade dos dados? -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Ponto por virgula
2015-02-11 15:06 GMT-02:00 Pedro B. Alves pedroalve...@gmail.com: Acho que realmente devo ter me expressado errado. Não é questão de erro, só de termos informações suficientes para falar algo além de dicas genéricas. Vamos lá, eu tenho um sistema de cadastro. que possui um campo numérico(10,2) PG 9.3 Foi formatado o PC Que PC é esse? O que ele roda? Tanto o sistema aplicativo quanto sua interface e base de dados? e quando instalei novamente o PG, agora está mostrando os campos de todo o sistema quando numérico, está no formato 100.00 e não 100,00 sendo que é a mesma configuração que antes. só foi formatado. Esse sistema é o quê, HTML ou VB ou…? Ele conecta como? Qual a configuração de local que ele envia ao PostgreSQL? Primeiramente achei que fosse algo do S.O. (Windows 8 64bits) Mas ai verifiquei que está correto no S.O então parti para o postgresql.conf pois a data também estava errada estava (01/24/2015) ou seja, MDY, alterei para DMY e funcionou. Então concluo que seja alguma configuração no postgresql.conf Não necessariamente. Não sei de mais algo que possa influenciar, senão passava mais informações. Basicamente, as configurações de local (C, pt_BR, en_US c) devem estar coerentes entre a base de dados, o sistema operacional e o aplicativo. O postgresql.conf só dá uma configuração padrão, que pode ser alterada, pela ordem, pela base, pela sessão, pelo aplicativo. Se o aplicativo não especifica nada, pode ser que ele use o definido no SO. Estou meio enferrujado, então posso ter me enganado algures. Mas, no teu caso, eu primeiro verificaria qual o local desejado (por exemplo, pt_BR.UTF-8), e se é o mesmo da base; verificaria se isso está configurado no MS Windows; e o que a aplicação usa. Por segurança, eu sempre botava pt_BR.UTF-8 no SO e no postgresql.conf antes de criar a base, e criava em pt_BR.UTF-8 também; assim, se o aplicativo não especificasse, ele poderia herdar um valor coerente do ambiente. Acho que não consegui explicar direito, mas tomara que te ajude a entender o problema. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Ponto por virgula
2015-02-11 9:26 GMT-02:00 Pedro B. Alves pedroalve...@gmail.com: Possivelmente o lc_numeric esteja diferente de um para outro. Está lc_numeric = 'C' Essa configuração é uma espécie de configuração básica para inglês estadunidense, meio que genérica. Normalmente você quer algo mais específico, como pt_BR, en_GB, fr_FR… como configurar depende do ambiente, mas o básico é algo que faça sentido e esteja coerente entre SOs, SGBD e aplicações. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Ponto por virgula
2015-02-11 10:24 GMT-02:00 Pedro B. Alves pedroalve...@gmail.com: Tentei utilizar o pt_BR, mas quando subo o serviço ele dá erro. Diz que o serviço não pode ser iniciado. Faltam detalhes. Tentou como, em que sistema? Qual a mensagem exatamente? -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] PostgreSQL x CentOS 7.0
2015-02-11 10:19 GMT-02:00 Fábio Gibon gi...@comexsystem.com.br: gostaria de saber se há algum ponto negativo ou de alerta em usar o PostgreSQL no CentOS 7.0.1406 (64bits)? Não. Somente se lembre que CentOS é um /clone/ do Red Hat, para ser usado em situações onde se quer manter compatibilidade com o mesmo — por exemplo, uma exigência burocrática de se usar Red Hat por ser homologado por um sistema proprietário, e aí se quer o CentOS para ambientes de testes. Se puder escolher, prefira uma distribuição autônoma, como o Debian. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] PostgreSQL x CentOS 7.0
2015-02-11 10:43 GMT-02:00 Fábio Gibon gi...@comexsystem.com.br: Obrigado Dutra. A minha preocupação nem é tanto com o CentOS em si, mas sim com a versão 7, pois temos um outro cliente com CentOS e roda legal, mas é a versão anterior. Para ficares mais tranqüilo, leia os /release notes/ tanto do SO quanto do SGBD. Mas, de maneira geral, além do Red Hat ser bem conservador, o CentOS ainda sai com algum atraso, portanto a probabilidade de permanecerem problemas é relativamente baixa. Dá também para fazer uma pesquisa por defeitos relatados, por exemplo http://www.postgresql.org/search/?m=1l=8q=CentOS -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] PostgreSQL x ArcGIS
2015-02-10 15:48 GMT-02:00 veronica.san...@ibge.gov.br: Prezados, boa tarde Boa tarde! Mas não entendemos o que levaria ao produto restringir o SO do SGBD em Windows, Red Hat e SUSE Enterprise se o servidor do SGBD não é compartilhado com o servidor do produto. Comodidade do fornecedor do produto, em ter de lidar com menos variáveis de configuração. Atualmente temos diversos servidores PostgreSQL rodando no CentOS sem qualquer problema com diversas aplicações (produtos open source ou aplicações desenvolvidas internamente usando desde Java a .Net). Claro, ele é um /clone/ quase perfeito do Red Hat. E poderia usar Debian também, provavelmente com vantagens. 1) Alguém conhece (ou consegue imaginar) alguma justificativa técnica para que um produto estabeleça restrições na camada subjacente do SGBD (ou seja o SO)? Estritamente técnica, não. Só conveniência do fornecedor, mesmo. 2) Sendo o PostgreSQL um software livre, pode um software proprietário fazer este tipo de restrição? Não é restrição, e nada tem a ver com licenciamento. É só um provedor de serviços, impondo condições porque pode, quer e lhe convém. Ninguém é obrigado a usar ArcGIS; eu particularmente acho isso até burrice, dados os sistemas livres que há nesse mercado. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] PostgreSQL x ArcGIS
2015-02-10 16:14 GMT-02:00 George Silva georger.si...@gmail.com: Só acho improdutivo nós, em geral, ficar criticando a escolha que nem sempre é de quem está pedindo suporte. Certamente não é produtivo. Mas produtividade não é a única razão para fazer algo, às vezes é desabafo mesmo. Exatamente porque quem pede suporte não é culpado é que fico à vontade (talvez erroneamente) em dar nome aos bois. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] PostgreSQL x ArcGIS
2015-02-10 16:06 GMT-02:00 George Silva georger.si...@gmail.com: Assim, não seria radical em chamar o uso do ArcGIS de burrice, mas realmente existem opções. Mas imagino que essa escolha, estava fora do escopo de trabalho da nossa colega, portanto não convém censurar ela pelo acordo que a instituição dela fez. Ninguém o fez. Ela só tem a situação nada invejável de ter de dar suporte; alguém mais tomou a decisão. Posso imaginar que haja circunstâncias atenuantes, mas hoje em dia decidir por um sistema proprietário está cada vez mais difícil de justificar. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] PostgreSQL x ArcGIS
2015-02-10 15:53 GMT-02:00 Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org: Ninguém é obrigado a usar ArcGIS; eu particularmente acho isso até burrice, dados os sistemas livres que há nesse mercado. Mil perdões pela expressão grosseira, conto com vossa compreensão e tolerância. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tabelas não utilizadas
2015-02-09 15:48 GMT-02:00 Fabrízio de Royes Mello fabri...@timbira.com.br: IMHO, antes de remover qualquer objeto do seu banco, vc deve partir do inverso, ou seja, ver os objetos (tabelas, indices, funcoes, etc) que sua aplicação usa e verificar na base quais *não* estão nessa lista. Supondo que se controle todos os programas que tem acesso. Nem sempre é verdade. Se vc versiona o schema do seu banco, essa informação é bem fácil de obter, caso contrário vc deve pensar seriamente em fazer isso. Boiei. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tabelas não utilizadas
2015-02-09 16:12 GMT-02:00 Everton Berz everton.b...@gmail.com: Se vc versiona o schema do seu banco, essa informação é bem fácil de obter, caso contrário vc deve pensar seriamente em fazer isso. Boiei. http://thedailywtf.com/articles/Database-Changes-Done-Right Mas o que tem isso a ver com que objetos estão ou não sendo usados? Indiretamente, sim, tem como verificar nas diferenças de versão quais objetos deixaram de ser usados — embora para isso seja relevante o código dos programas aplicativos, não o da estrutura da base; esta só será relevante se houver certeza de que todo o acesso à base é feito por procedimentos armazenados. Mas minha experiência é que, mesmo quando se versiona código, há mais coisas entre o céu e a terra que imagina nossa vã filosofia… -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] postgres no Dreamhost
2015-02-09 16:31 GMT-02:00 Natanael Roberto Rodrigues nr.n...@gmail.com: Aguem poderia me informar se o DreamHost tem suporte ao Postgres? Certamente, alguém na Dreamhost. Ou o Google, cujo primeiro resultado é para Dreamhost PostgreSQL me foi http://wiki.dreamhost.com/PostgreSQL -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] BOOL e BOOLEAN Diferenças
2014-07-22 17:50 GMT-03:00 Matheus Saraiva matheus.sara...@gmail.com: Quando falo objeto me refiro a qualquer coisa que possa ser bool, uma coluna, uma variável, retorno de uma função, etc. Não sei se o termo 'objeto' está correto no dialeto dos DBAs, afinal, não sou eu um. Nem é questão de ser correto ou não, é que é muito genérico. Por exemplo, uma coluna já um termo meio bagunçado, mas nenhuma de suas acepções que eu saiba tem um valor escalar. Talvez você queria dizer um atributo, caso em que ele pode ter um valor que pode ser 0 ou 1 se seu tipo for BOOL. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Ferramenta para programação
2014-07-21 10:28 GMT-03:00 Alexsander Rosa alexsander.r...@gmail.com: Em 17 de julho de 2014 17:22, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: http://www.slate.com/articles/technology/bitwise/2014/05/oldest_software_rivalry_emacs_and_vi_two_text_editors_used_by_programmers.html Não tem fim… que é vim pronunciado em alemão… -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Ferramenta para programação
2014-07-17 9:21 GMT-03:00 Matheus Saraiva matheus.sara...@gmail.com: Que Ferramenta/IDE/Editor usar para programar para postgre? Estou criando uma funções com o pgModeler, mas não estou muito satisfeito. Gosto do GNU Emacs com o modo SQL. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Artigo sobre desempenho do PostgreSQL no FreeBSD
2014-07-17 15:04 GMT-03:00 Ricardo Campos Passanezi ri...@ige.unicamp.br: Como vez ou outra surge o assunto performance por aqui, segue uma mensagem enviada para listas do freebsd a respeito do desempenho do PostgreSQL. Obrigado! O PostgreSQL, ainda como Ingres, foi em grande parte desenvolvido no BSD Unix, e este foi bastante desenvolvido para atender o Ingres. O bom filho à casa torna. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Ferramenta para programação
2014-07-17 17:16 GMT-03:00 Bruno Silva bemanuel...@gmail.com: On Thu, Jul 17, 2014 at 4:01 PM, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org wrote: Nunca vi editor melhor que o Emacs… e olha que vim de tentar aprender o concorrente! Mas que funcionalidades o Emacs tem que o ViM não tem na área do SQL? Nem sei. Nunca nem vi ninguém usar SQL dentro de nenhum *vi*, estava mais brincando, viu? Mas já vi que o GNU Emacs, sendo baseado em Lisp, é muito mais flexível que qualquer outro editor já visto. Já vi que é hora de parar esta discussão nunca vista aqui… -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Ferramenta para programação
2014-07-17 17:29 GMT-03:00 Bruno Silva bemanuel...@gmail.com: PSQL + ViM e às vezes Gedit ( por conta da coloração ). Aí corro pro SQLFormat[1], quando o código não vem bem identado. Então pronto. O GNU Emacs faz tudo isso: colore e identa. E personalizável em ambas as funções. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Mover pasta data do PostgreSQL para caminho alternativo
2014-07-14 17:12 GMT-03:00 Eduardo Alexandre eduardog...@gmail.com: Tenho a necessidade de passar a armazenar os dados do PostgreSQL em um disco montado em /mnt/postgresql, cujo banco já possui dados. Não entendi direito, pode refrasear? (existe isso em pt_BR?) De qualquer maneira, /mnt não está de acordo com o FHS. Há uma melhor forma de fazer isso de forma garantida ou basta um rsync de /var/lib/pgsql para a nova pasta e mudar os caminhos no arquivo de configuração em /etc/init.d/postgresql-9.3? Eu sugeriria montar o novo volume em /srv/pg ou algo assim, e alterar o /etc de acordo. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Chamar o JAR pelo PHP
2014-07-10 12:20 GMT-03:00 Abel Viera - Fundaçao Pio XII gvie...@hcancerbarretos.com.br: Alguem poderia me passar o script de chamar um JAR que esta no servidor Linus atraves de uma aplicação PHP.. Lista errada, tente alguma de PHP, de Linux (Linus é o autor, não o núcleo) ou de Java. Deve ter alguém aqui que saiba responder, mas desencorajamos respostas a perguntas totalmente fora de tópico. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] PostgreSQL com o Microsiga Protheus
2014-07-09 11:49 GMT-03:00 Roberto Mello roberto.me...@gmail.com: Participei da comunidade do OpenERP alguns anos atrás, na localização Brasileira. O projeto parecia estar muito, mas muito em fluxo ainda, tudo mudando muito. O tempo passou, e agora que você mencionou, fui olhar novamente, e não consigo fazer sentido do que está sendo dito. Não encontrei (mas também não procurei tanto assim) lugar que me responda coisas simples, como: 1) Como está a localização Brasileira? 2) Já suporta NFC-e? 3) Suporta as exigências de frente de loja? (não pode depender de conexão on-line) Vou continuar procurando. Obrigado pelas sugestões. Copiei o Ananias. Ele deve poder responder. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] PostgreSQL com o Microsiga Protheus
2014-07-09 12:12 GMT-03:00 Flavio Henrique Araque Gurgel fha...@gmail.com: Alguém me disse aqui na terra de Victor Hugo que site com informação demais e sem rolagem bonitinha sobre meia dúzia de informações sem nexo e feito apenas com buzzwords é old school e feio. Infelizmente estamos ficando velhos antes dos 40, porque o mundo da tecnologia anda depressa demais. Amiúde, para trás. Aliás, o do futebol brasileiro também. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Fwd: PostgreSQL com o Microsiga Protheus
Repassando a resposta do Ananias: -- Forwarded message -- From: Ananias Filho kra...@gmail.com Date: 2014-07-09 14:50 GMT-03:00 Subject: Re: [pgbr-geral] PostgreSQL com o Microsiga Protheus To: Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org, roberto.me...@gmail.com Olá Leandro e Roberto, boa tarde! Respondendo as suas dúvidas, 1) Como está a localização Brasileira? O que você precisa da Localização? Hoje a parte contábil é totalmente funcional em relação a legislação brasileira em vigor. O problema agora é com SPED e eSOCIAL que já serão obrigatórios a partir de 2015 para todos. o eSOCIAL ainda não tem o manual final homologado e por isso não há como desenvolver sem as especificações. O SPED está variando de caso a caso porque há a necessidade de mapeamento das informações para envio. É só uma questão de mapeamento do enquadramento do cliente. 2) Já suporta NFC-e? Já estamos trabalhando com o desenvolvimento da NFC-e para o primeiro cliente, de acordo com o calendário de entregas aqui da empresa, em 45 dias estaremos lançando a base dele no GIT do Odoo/Localização Brasileira e cada um poderá customizar de acordo com a necessidade. O mesmo é feito com a NF-e que já é totalmente funcional no Odoo/OpenERP. 3) Suporta as exigências de frente de loja? (não pode depender de conexão on-line) A frente de loja ainda é um pouco problemático por causa do PAF-ECF, porém, com a NFC-e ficará mais fácil. A exigência da independência de conectividade já é realidade na versão 8 com HTML 5. O grande problema da versão 8 é a questão da Localização Brasileira que só deu o start válido na última segunda-feira, 7/7/2014 por causa do lancamento oficial. Portanto, é legal aguardar mais uns 30-60 dias para sabermos qual a data final para entrega. Qualquer dúvida, estou a disposição! Ananias Filho - kram3r 2014-07-09 11:52 GMT-03:00 Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org: 2014-07-09 11:49 GMT-03:00 Roberto Mello roberto.me...@gmail.com: Participei da comunidade do OpenERP alguns anos atrás, na localização Brasileira. O projeto parecia estar muito, mas muito em fluxo ainda, tudo mudando muito. O tempo passou, e agora que você mencionou, fui olhar novamente, e não consigo fazer sentido do que está sendo dito. Não encontrei (mas também não procurei tanto assim) lugar que me responda coisas simples, como: 1) Como está a localização Brasileira? 2) Já suporta NFC-e? 3) Suporta as exigências de frente de loja? (não pode depender de conexão on-line) Vou continuar procurando. Obrigado pelas sugestões. Copiei o Ananias. Ele deve poder responder. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] log_filename
2014-07-07 23:47 GMT-03:00 Matheus de Oliveira matioli.math...@gmail.com: Nesse formato de arquivo o PostgreSQL não irá apagar arquivos antigos, só irá gerar novos. Então você terá que cuidar de apagar os antigos por conta própria. Isso parece uma tarefa para o log_rotate do Debian (deve ter noutros GNU/Linuces). -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] PostgreSQL com o Microsiga Protheus
2014-07-08 10:05 GMT-03:00 Roberto Mello roberto.me...@gmail.com: Alguém tem uma sugestão de ERP para pequenas empresas que preste? Que suporte Linux e PostgreSQL? Um ex‐executivo da Oracle criou o Compière, que foi portado para PostgreSQL e desenvolvido como Adempière. Havia uma localização, não sei como anda. Me parece que há uma comunidade em torno do PostBooks ou algo assim. Mas o que creio que anda melhor seria o OpenERP, renomeado para Odoo. Tem mais de uma empresa de suporte tupiniquim, inclusive uma dum conhecido meu, o Ananias Pereira Batista filho que, que me lembre, enfatiza bastante a dobradinha Debian GNU/Linux e o PostgreSQL. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] PostgreSQL com o Microsiga Protheus
2014-07-08 10:50 GMT-03:00 Alexsandro Haag alexsandro.h...@gmail.com: no Brasil hoje existem comunidades brasileiras de localização de ERPs livres estrangeiros. Um exemplo é o OpenERP (hoje Odoo) licenciado sob AGPL, Tinha esquecido que o Odoo é AGPL. Isso é muito bom! -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] PostgreSQL com o Microsiga Protheus
2014-07-05 11:45 GMT-03:00 Roberto Mello roberto.me...@gmail.com: Ainda não trabalhei com os sistemas da Totvs, mas recentemente conversei com um franqueado deles sobre sua implantação, e ele disse que o PostgreSQL era um dos bancos suportados. Não procede essa informação então? Procede. Mas nada da Microsiga (me recuso a chamar de Totvs, que nem é pronunciável em português e é só uma tentativa de deixar para trás a merecida péssima fama) é simples. Eles suportam. Mas só homologam versões ancestrais, e de má vontade. Funciona muito bem, melhor que SGBDs teoricamente mais suportados. Mas tem de ter alguma cautela e paciência ao lidar com os técnicos deles, que não são melhores que o sistema. O que esperar de um sistema criado para Clipper? Pelo menos, essa era a situação até a última vez que tive contato com eles, uns cinco anos e meio atrás. Não deixou saudades. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Paralelismo
2014-07-03 10:04 GMT-03:00 Bruno Silva bemanuel...@gmail.com: 2014-07-03 7:48 GMT-03:00 Flavio Henrique Araque Gurgel fha...@gmail.com: Antes de qualquer coisa fui pesquisar no histórico mas o sistema está fora do ar, ao menos na hora em que acessei. Estamos com problemas mesmo, há pessoas trabalhando nisso. Desculpa aí Dutra, mas... Oi? Fui eu não… estou por fora… -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] AUTOCOMMIT OFF - Permanente
2014-06-30 10:29 GMT-03:00 JotaComm jota.c...@gmail.com: Fique curioso: Por que deixar o autocommit = OFF? Segurança de não efetivar antes de emitir um COMMIT. E seria mais confortável para mim que precisar sempre lembrar de começar uma transação, e sempre configurar cada ferramenta. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] AUTOCOMMIT OFF - Permanente
2014-06-30 11:01 GMT-03:00 Tiago José Adami adam...@gmail.com: Ter essa opção no banco de dados é irrelevante. O pgAdmin deveria ter uma configuração própria para isso, a exemplo de outras ferramentas Por que deveria? Existe uma miríade de ferramentas que sobreporiam a configuração no banco de dados. Aí é problema do usuário delas. A responsabilidade da integridade dos dados deve ser de quem executa o comando/instrução SQL. E para eximir o gestor de dados os aplicativos/programas devem ser bem testados e os usuários devem saber o que estão fazendo. Sim, e papai Noel este ano não vai esquecer de mim, e já estou com água na boca dos ovos que o coelhinho da Páscoa deixará no meu quintal. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] http://blogs.enterprisedb.com/2014/06/24/message-to-sql-server-users-everything-youve-been-told-is-wrong/
2014-06-30 14:26 GMT-03:00 Rubens José Rodrigues rubens.rodrig...@batistarepresentacoes.com: PSC Favor não colocar o conteúdo (http://blogs.enterprisedb.com/2014/06/24/message-to-sql-server-users-everything-youve-been-told-is-wrong/) na linha de assunto. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
