Lançada a versão 8.1 do PostgreSQL
“Foi lançada ontem (08/11) a versão 8.1 do PostgreSQL. Entre as diversas novas características se destacam a otimização para funcionamento do banco com servidores de grande porte. A nova versão do SGBD suporta máquinas com terabytes de memória e diversos processadores. Nas 'release notes' são listadas e detalhadas outras características que foram adicionadas ou modificadas/otimizadas. A NewsForge também traz uma reportagem com análise da nova versão incluindo depoimentos de Bruce Momjian, um dos principais desenvolvedores do PGDG. Vale uma olhada, esta nova versão (mais uma vez) faz crer que o slogan "The world's most advanced open source Database" se justifique. O avanço dos SGBDs de código aberto parece explicar porque a anteriormente, onipotente, Oracle, esteja gradativamente baixando seus preços e sendo mais agressiva ao oferecer versões sem custo para desenvolvedores (com diversas restrições).” A nota foi enviada por Daniel Gaspary (dgasparyΘgmail·com) , que enviou este link para mais detalhes.
Veja abaixo o anúncio completo em português enviado por Diogo Biazus, PostgreSQL Regional Contact no Brasil.
Lançamento do PostgreSQL 8.1
“8 Novembro de 2005, Frankfurt, Alemanha (OpenDBCon): O Grupo Global de
Desenvolvimento do PostgreSQL tem o prazer de anunciar a versão 8.1 do
PostgreSQL, reforçando sua liderança como o mais avançado Sistema Gerenciador
de Bancos de Dados de código aberto. Planejado, construído e testado por uma
grande e crescente comunidade e apoiado por um número cada vez maior de
corporações patrocinadoras e companhias de suporte, a versão 8.1 expandirá a
gama de desenvolvimento de aplicações para o PostgreSQL. A nova versão inclui
melhorias de performance e características avançadas de SQL, que suportarão
maiores data warehouses, grande volume de processamento de transações, e
software distribuído corporativo mais complexo.
Essas características darão continuidade às tendências estabelecidas na versão
anterior. A versão 8.0 teve um milhão de downloads nos seus primeiros sete
meses, em comparação com os aproximadamente 300.000 downloads da versão
anterior, para o mesmo período.
"O projeto está claramente avançando na mente dos usuários de bancos de
dados," disse Lance Obermeyer, Diretor de Produtos da Pervasive Software, uma
das corporações patrocinadoras do PostgreSQL. "Dado o crescente interesse na
infra-estrutura de software de código aberto, esperamos que o PostgreSQL ganhe
ainda mais força".
Novas Características Avançadas do Bancos de Dados
--------------------------------------------------
Papéis: o PostgreSQL agora suporta papéis de bancos de dados, os quais
simplificam o gerenciamento de grande número de usuários que tenham
sobreposições de direitos de uso do banco de dados complexas.
Parâmetros IN/OUT: as funções do PostgreSQL agora suportam os parâmetros IN,
OUT e INOUT, os quais melhoram substancialmente o suporte de lógicas de
negócios complexas para aplicações J2EE e .NET.
Commit em duas fases (Two-Phase Commit, ou 2PC): demandada há muito para
aplicações WAN (Wide-Area Network) e data centers heterogêneos que utilizam o
PostgreSQL, esse recurso permite transações compatíveis com o padrão ACID
através de servidores distantes entre si.
Melhorias na Performance
------------------------
Performance de Multiprocessadores (SMP) Melhorada: o gerenciador de buffer da
versão 8.1 foi aprimorado para escalonar de forma praticamente linear com o
número de processadores, resultando em ganhos significativos de performance
em servidores de 8 vias, 16 vias, dual-core e multi-core.
Bitmap Scan: os índices serão convertidos dinamicamente para mapas de bits na
memória quando apropriado, resultando em uma performance de índices até 20
vezes mais rápida em consultas complexas em tabelas muito grandes. Isso
também ajuda a simplificar o gerenciamento do banco de dados reduzindo
enormemente a necessidade de índices multi-colunas.
Particionamento de Tabelas: o planejador de consultas agora é capaz de evitar
a varredura em seções inteiras de uma grande tabela usando uma técnica
conhecida como Exclusão por Restrições. Similar ao Particionamento de Tabela
encontrado em outros SGBDs, este recurso melhora tanto a performance quanto o
gerenciamento de dados para tabelas com vários gigabytes.
Bloqueio de Linhas Compartilhada: o PostgreSQL, com seu mecanismo de bloqueio
"melhor que o nível de bloqueio de linha", suporta agora níveis de
concorrência ainda mais altos, através da adição de bloqueios de linhas
compartilhadas para chaves estrangeiras. Este tipo de bloqueio melhorará a
performance de inserções e alterações em várias aplicações que tem alto volume
de processamento de transações em tempo real.
"O PostgreSQL 8.1 oferece um grande aumento de performance em nossos
servidores de produção Opteron bi-processados", disse Merlin Moncure, DBA da
Reliable Computer Solutions. "Mais especificamente, percebo uma redução em
torno de 20% em tempo de execução de consultas simples e mais 20% de redução
da carga do processador, para uma surpeeendente melhoria entre 20% e 40% nas
características de carga dos servidores."
Existem mais de 120 outras melhorias, algumas das quais detalhadas em nossa
Nota de Lançamento da Versão 8.1 http://www.postgresql.org/about/press/presskit81.html.br.
Diogo Biazus
PostgreSQL Regional Contact, Brasil
br@postgresql.org
(51) 9141 0130
Sobre o PostgreSQL
------------------
O PostgreSQL é o trabalho coletivo de centenas de desenvolvedores, construído
em vinte anos de desenvolvimento que se iniciou na Universidade de Berkeley,
na Califórnia. Com seu suporte maduro de características de nível empresarial
como transações, funções, gatilhos e subconsultas, o PostgreSQL é utilizado
por várias empresas e agências do governo. O PostgreSQL é distribuído sob a
licença BSD, que permite o uso e distribuição sem custos para uso em
aplicações comerciais ou não comerciais.” A nota foi enviada por Diogo de Oliveira Biazus (diogobΘgmail·com) , que enviou este link para mais detalhes.
(postado por Augusto Campos)
Comentários dos leitores
Comentário de Felipe Raposo
10/11/05 9:56 - usuário registrado #226
Gatilhos: Eu trabalho com os softwares da Microsiga e eles também utilizam o termo "gatilho".
Felipe Raposo
Felipe Raposo
Comentário de nemesis
10/11/05 12:49 - usuário registrado #1514
Viva o PostgreSQL!!
: Viva o PostgreSQL!!
Rapaz, eu estava outro dia vendo a API C da M$ para acesso à seu SQL Server -- que lamentavelmente tenho que usar no trabalho. Mera curiosidade. Seus arquivos header são a coisa mais esquizofrênica que já vi na vida! A impressão que tive foi que são feitas propositadamente assim para que o cara simplesmente não use C. Ou use C++ com suas IDEs. É isso mesmo: são arquivos feitos para serem processados por ferramentas próprias, não por humanos.
Já os headers do PostgreSQL são uma maravilha de clareza e concisão. Você não precisa nem de documentação de referência: os headers são suficientes e auto-explicativos.
Será que essa diferença brutal é fruto do papel primordial que C desempenha em muitos projetos de software livre e pouco nos comerciais?...
em tempo: a API de MySQL também é meio triste em comparação. Onde já se viu um mysql_connect obsoleto em favor de mysql_real_connect? e quando mudarem a API de novo? mysql_super_duper_connect??
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Rapaz, eu estava outro dia vendo a API C da M$ para acesso à seu SQL Server -- que lamentavelmente tenho que usar no trabalho. Mera curiosidade. Seus arquivos header são a coisa mais esquizofrênica que já vi na vida! A impressão que tive foi que são feitas propositadamente assim para que o cara simplesmente não use C. Ou use C++ com suas IDEs. É isso mesmo: são arquivos feitos para serem processados por ferramentas próprias, não por humanos.
Já os headers do PostgreSQL são uma maravilha de clareza e concisão. Você não precisa nem de documentação de referência: os headers são suficientes e auto-explicativos.
Será que essa diferença brutal é fruto do papel primordial que C desempenha em muitos projetos de software livre e pouco nos comerciais?...
em tempo: a API de MySQL também é meio triste em comparação. Onde já se viu um mysql_connect obsoleto em favor de mysql_real_connect? e quando mudarem a API de novo? mysql_super_duper_connect??
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Comentário de Ananias
10/11/05 21:01 - usuário registrado #444
Mas é: são arquivos feitos para serem processados por ferramentas próprias, não por humanos.
Mas esses arquivos SÃO feitos para serem processados por máquinas. A documentação, essa sim deve ser "processada" por humanos.
--
http://br-linux.blogspot.com
Não é tira-teima de nada, mas é interessante
Mas esses arquivos SÃO feitos para serem processados por máquinas. A documentação, essa sim deve ser "processada" por humanos.
--
http://br-linux.blogspot.com
Não é tira-teima de nada, mas é interessante
Comentário de Patola
10/11/05 21:48 - usuário registrado #184
Ahhhhh...: Mas esses arquivos SÃO feitos para serem processados por máquinas. A documentação, essa sim deve ser "processada" por humanos.
Você não programa, não é mesmo?
Certamente que a documentação da API é importante. Mas headers compreensíveis e organizados também são essenciais para uma programação boa. Um belo exemplo de desorganização que atrapalha o uso é o dado pelo próprio nemesis, do mysql_connect x mysql_real_connect.
Na boa, cara. Parece que você discorda só pra ter o prazer de discordar. De que valeu acrescentar esse comentário ao do nemesis?
--
LinuxFUD, o TIRA-TEIMA dos ataques ao software livre: http://linuxfud.org
Você não programa, não é mesmo?
Certamente que a documentação da API é importante. Mas headers compreensíveis e organizados também são essenciais para uma programação boa. Um belo exemplo de desorganização que atrapalha o uso é o dado pelo próprio nemesis, do mysql_connect x mysql_real_connect.
Na boa, cara. Parece que você discorda só pra ter o prazer de discordar. De que valeu acrescentar esse comentário ao do nemesis?
--
LinuxFUD, o TIRA-TEIMA dos ataques ao software livre: http://linuxfud.org
Comentário de Ananias
10/11/05 22:03 - usuário registrado #444
Já programei...: ... e foram muito poucas as vezes em que precisei ler os headers, para entender a API. Isso só se faz no último caso, quando não existe documentação adequada.
Veja, por exemplo a documentação do Gtk. Instale e execute o programa devhelp, e o livro do Gtk. Com a documentação completa NUNCA será necessário consultar os headers, que SÃO ARQUIVOS FEITOS PARA SEREM LIDOS POR UM COMPILADOR, e não pelo usuário (da API) em busca de informações.
Imagine, por exemplo, se eu quisesse descobrir como utilizar a função strncpy. O que você faria? Abrir o strings.h? Pegar o código fonte da libc? Ou executar "man 3 strncpy"?
Documentação serve para documentar.
--
http://br-linux.blogspot.com
Não é tira-teima de nada, mas é interessante
Veja, por exemplo a documentação do Gtk. Instale e execute o programa devhelp, e o livro do Gtk. Com a documentação completa NUNCA será necessário consultar os headers, que SÃO ARQUIVOS FEITOS PARA SEREM LIDOS POR UM COMPILADOR, e não pelo usuário (da API) em busca de informações.
Imagine, por exemplo, se eu quisesse descobrir como utilizar a função strncpy. O que você faria? Abrir o strings.h? Pegar o código fonte da libc? Ou executar "man 3 strncpy"?
Documentação serve para documentar.
--
http://br-linux.blogspot.com
Não é tira-teima de nada, mas é interessante
Comentário de Patola
10/11/05 22:16 - usuário registrado #184
Eu não disse que documentação não serve: Documentação é útil, eu não neguei isso. O que eu falei é que o header também é. Imagine se strncpy se chamasse xAge4Bn...
Os headers são feitos pra serem processados por máquinas, mas usados por humanos (programadores). E já que você falou do Gtk, por que acha que a API tem nomes legíveis como "gtk_entry_new_with_max_length"? Pra ajudar o COMPUTADOR a processar?
--
LinuxFUD, o TIRA-TEIMA dos ataques ao software livre: http://linuxfud.org
Os headers são feitos pra serem processados por máquinas, mas usados por humanos (programadores). E já que você falou do Gtk, por que acha que a API tem nomes legíveis como "gtk_entry_new_with_max_length"? Pra ajudar o COMPUTADOR a processar?
--
LinuxFUD, o TIRA-TEIMA dos ataques ao software livre: http://linuxfud.org
Comentário de Ananias
10/11/05 22:39 - usuário registrado #444
Headers: O que eu falei é que o header também é. Imagine se strncpy se chamasse xAge4Bn...
Qual é a relação entre o nome da função e a forma como o header é escrito?
Eu concordo que a nomenclatura de funções, variáveis, etc, é extremamente importante, mas isso independe do fato de um header ser legível, ou não.
Nunca usei o SQL Server, especificamente, mas já utilizei a MFC, e um pouco de .NET, e nunca vi casos de tão gritantes discrepâncias entre a nomenclatura e o resultado. (ainda que o header seja ilegível)
--
http://br-linux.blogspot.com
Não é tira-teima de nada, mas é interessante
Qual é a relação entre o nome da função e a forma como o header é escrito?
Eu concordo que a nomenclatura de funções, variáveis, etc, é extremamente importante, mas isso independe do fato de um header ser legível, ou não.
Nunca usei o SQL Server, especificamente, mas já utilizei a MFC, e um pouco de .NET, e nunca vi casos de tão gritantes discrepâncias entre a nomenclatura e o resultado. (ainda que o header seja ilegível)
--
http://br-linux.blogspot.com
Não é tira-teima de nada, mas é interessante
Comentário de ninguém
11/11/05 0:41
Ô...: lawyers aren't programmers...they're masters of retorica..
Comentário de nemesis
11/11/05 1:39 - usuário registrado #1514
conversa!: "por exemplo a documentação do Gtk. Com a documentação completa NUNCA será necessário consultar os headers"
Exceto, é claro, quando você perceber que documentação de projetos open-source nem sempre é completa e atualizada em sincronia com a última versão. Leva tempo e nem sempre parece valer o trabalho, se a API for bem escrita...
"SÃO ARQUIVOS FEITOS PARA SEREM LIDOS POR UM COMPILADOR"
Sem dúvida. Aliás, todo o código-fonte, já que o único resultado que vale mesmo é o binário final rodando. É exatamente por esse motivo que não me preocupo com nomes significativos para funções ou variáveis, já que o compilador se vira bastante bem com nomes como x, x2, x3, f1, f2 e por aí vai... sarcasmo, ok?
Sério, headers e interfaces são a documentação mínima para humanos e é bom que sejam bem escritos...
"Imagine, por exemplo, se eu quisesse descobrir como utilizar a função strncpy. O que você faria? Abrir o strings.h? Pegar o código fonte da libc? Ou executar 'man 3 strncpy'?"
eu posso fazer
$ grep -i strncpy /usr/include/strings.h
e obter uma descrição bastante sucinta e útil. Eu só leria a man page da primeira vez, se nunca tivesse usado, mas seriamente, a maioria das vezes os headers me bastam...
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Exceto, é claro, quando você perceber que documentação de projetos open-source nem sempre é completa e atualizada em sincronia com a última versão. Leva tempo e nem sempre parece valer o trabalho, se a API for bem escrita...
"SÃO ARQUIVOS FEITOS PARA SEREM LIDOS POR UM COMPILADOR"
Sem dúvida. Aliás, todo o código-fonte, já que o único resultado que vale mesmo é o binário final rodando. É exatamente por esse motivo que não me preocupo com nomes significativos para funções ou variáveis, já que o compilador se vira bastante bem com nomes como x, x2, x3, f1, f2 e por aí vai... sarcasmo, ok?
Sério, headers e interfaces são a documentação mínima para humanos e é bom que sejam bem escritos...
"Imagine, por exemplo, se eu quisesse descobrir como utilizar a função strncpy. O que você faria? Abrir o strings.h? Pegar o código fonte da libc? Ou executar 'man 3 strncpy'?"
eu posso fazer
$ grep -i strncpy /usr/include/strings.h
e obter uma descrição bastante sucinta e útil. Eu só leria a man page da primeira vez, se nunca tivesse usado, mas seriamente, a maioria das vezes os headers me bastam...
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Comentário de Ananias
11/11/05 3:26 - usuário registrado #444
Pera aí...: Exceto, é claro, quando você perceber que documentação de projetos open-source nem sempre é completa e atualizada em sincronia com a última versão.
No começo da conversa você estava criticando o SQL Server por ter headers ilegíveis. Agora, para justificar sua afirmação você está dizendo que a documentação de projetos open-source é ruim? Até a última vez que eu verifiquei - e faz tempo - o SQL Server não era Open Source.
Posso destacar, sem medo de estar errado, três coisas que a Microsoft sabe fazer muito bem: marketing, o Office e documentação.
$ grep -i strncpy /usr/include/strings.h
E não ia achar nada. A strncpy está definida no string.h. Tudo bem, fui eu que errei originalmente. Mas, pelo menos, eu posso me defender dizendo que eu não olho os headers. Já você...
--
http://br-linux.blogspot.com
Não é tira-teima de nada, mas é interessante
No começo da conversa você estava criticando o SQL Server por ter headers ilegíveis. Agora, para justificar sua afirmação você está dizendo que a documentação de projetos open-source é ruim? Até a última vez que eu verifiquei - e faz tempo - o SQL Server não era Open Source.
Posso destacar, sem medo de estar errado, três coisas que a Microsoft sabe fazer muito bem: marketing, o Office e documentação.
$ grep -i strncpy /usr/include/strings.h
E não ia achar nada. A strncpy está definida no string.h. Tudo bem, fui eu que errei originalmente. Mas, pelo menos, eu posso me defender dizendo que eu não olho os headers. Já você...
--
http://br-linux.blogspot.com
Não é tira-teima de nada, mas é interessante
Comentário de nemesis
11/11/05 14:07 - usuário registrado #1514
a-há!: "você estava criticando o SQL Server por ter headers ilegíveis. Agora, para justificar sua afirmação você está dizendo que a documentação de projetos open-source é ruim? Até a última vez que eu verifiquei - e faz tempo - o SQL Server não era Open Source."
Você esqueceu de mencionar que você mencionou a documentação do GTK+, que é notoriamente incompleta.
"marketing, o Office e documentação."
O marketing é o que faz a empresa sobreviver. O Office é o que faz com que ela continue seu monopólio. E a documentação é para suprir seus headers propositadamente deficientes. :)
É bom eles serem deficientes para te fazer crer que você absolutamente precisa das ferramentas deles para programar e de preferência as mais modernas com C#.
"E não ia achar nada. A strncpy está definida no string.h."
crap! eu testei com string.h, mas vi seu comentário com strings.h e pus igual...
só pra terminar: você acha que seria realmente necessário ler a documentação toda a respeito de strcpy? A documentação dessas ferramentas comerciais é incrivelmente rebuscada e é até difícil de se encontrar por ela...
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Você esqueceu de mencionar que você mencionou a documentação do GTK+, que é notoriamente incompleta.
"marketing, o Office e documentação."
O marketing é o que faz a empresa sobreviver. O Office é o que faz com que ela continue seu monopólio. E a documentação é para suprir seus headers propositadamente deficientes. :)
É bom eles serem deficientes para te fazer crer que você absolutamente precisa das ferramentas deles para programar e de preferência as mais modernas com C#.
"E não ia achar nada. A strncpy está definida no string.h."
crap! eu testei com string.h, mas vi seu comentário com strings.h e pus igual...
só pra terminar: você acha que seria realmente necessário ler a documentação toda a respeito de strcpy? A documentação dessas ferramentas comerciais é incrivelmente rebuscada e é até difícil de se encontrar por ela...
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Comentário de Ananias
11/11/05 20:31 - usuário registrado #444
Continua sem justificativa: Você esqueceu de mencionar que você mencionou a documentação do GTK+, que é notoriamente incompleta.
Isso ainda te deixa longe de uma justificativa plausível para reclamar do fato de os headers do SQL Server serem ilegíveis.
A não ser que você tenha reclamado originalmente do SQL Server em resposta a um comentário que eu só fiz depois da sua reclamação... o que seria um tanto quanto estranho.
--
http://br-linux.blogspot.com
Não é tira-teima de nada, mas é interessante
Isso ainda te deixa longe de uma justificativa plausível para reclamar do fato de os headers do SQL Server serem ilegíveis.
A não ser que você tenha reclamado originalmente do SQL Server em resposta a um comentário que eu só fiz depois da sua reclamação... o que seria um tanto quanto estranho.
--
http://br-linux.blogspot.com
Não é tira-teima de nada, mas é interessante
Comentário de nemesis
11/11/05 22:12 - usuário registrado #1514
pensei ter deixado claro...: ...que minha justificativa é que headers são a documentação mínima de referência, e devem ser legíveis por humanos, não somente por compiladores, como o resto do código fonte, aliás...
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Comentário de Patola
11/11/05 23:31 - usuário registrado #184
Mea culpa, mea culpa, mea maxima culpa: Nemesis, vamos admitir, estamos errados. Acho que essa dos headers é mais uma das coisas consideradas universal e inquestionavelmente corretas no br-linux, por seu criador e seus usuários. Somos cegos que precisam de um guia pra nos mostrar a luz. Não tem importância a Microsoft usar headers confusos pois eles serem claros ou obscuros não faz diferença na programação que os utiliza.
Agora que concordamos contigo, Ananias, nos diga: no fundo do seu coração, ao ficar flamejando com essas picuinhas, você acha que está abrindo nossos olhos ou simplesmente sendo chato?
--
LinuxFUD, o TIRA-TEIMA dos ataques ao software livre: http://linuxfud.org
Agora que concordamos contigo, Ananias, nos diga: no fundo do seu coração, ao ficar flamejando com essas picuinhas, você acha que está abrindo nossos olhos ou simplesmente sendo chato?
--
LinuxFUD, o TIRA-TEIMA dos ataques ao software livre: http://linuxfud.org
Comentário de nemesis
12/11/05 12:24 - usuário registrado #1514
hehe: "Somos cegos que precisam de um guia pra nos mostrar a luz."
Cegos sendo liderados por outro cego vão cair no primeiro buraco...
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Cegos sendo liderados por outro cego vão cair no primeiro buraco...
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Comentário de Ananias
12/11/05 17:21 - usuário registrado #444
Engraçado: Primeiro você diz: Exceto, é claro, quando você perceber que documentação de projetos open-source nem sempre é completa e atualizada em sincronia com a última versão.
O que nos leva a crer que os headers só são necessários quando a documentação não é completa, atualizada ou sincronizada com a última versão.
Depois, você coloca os headers como a fonte primordial de informação: minha justificativa é que headers são a documentação mínima de referência, e devem ser legíveis por humanos,
No caso original, o SQL Server, a documentação é farta, completa, atualizada e sincronizada, o que não cai no caso de "exceto quando a documentação é ruim", que você citou.
A sua crítica ainda é infudada. Se a documentação é suficiente, você não precisa utilizar a medida de exceção, e não de regra, que é ler os headers... pelo menos foi isso que você disse.
--
http://br-linux.blogspot.com
Não é tira-teima de nada, mas é interessante
O que nos leva a crer que os headers só são necessários quando a documentação não é completa, atualizada ou sincronizada com a última versão.
Depois, você coloca os headers como a fonte primordial de informação: minha justificativa é que headers são a documentação mínima de referência, e devem ser legíveis por humanos,
No caso original, o SQL Server, a documentação é farta, completa, atualizada e sincronizada, o que não cai no caso de "exceto quando a documentação é ruim", que você citou.
A sua crítica ainda é infudada. Se a documentação é suficiente, você não precisa utilizar a medida de exceção, e não de regra, que é ler os headers... pelo menos foi isso que você disse.
--
http://br-linux.blogspot.com
Não é tira-teima de nada, mas é interessante
Comentário de nemesis
12/11/05 18:27 - usuário registrado #1514
arre!: "os headers só são necessários quando a documentação não é completa, atualizada ou sincronizada com a última versão."
Eu não disse isso. Eu estava dando uma justificativa a mais para você ter os headers como referência, já que eles necessariamente têm de estar atualizados. Mesmo com documentação farta e atualizada, ainda acho a referência pelos headers mais adequada para a programação, se você já conhece a biblioteca: isso pq não quero gastar meu tempo precioso lendo parágrafos e mais parágrafos de explicações sobre a arquitetura e funcionamento da biblioteca.
Os headers são a API de uma biblioteca, são sua documentação mínima de referência e devem ser bem escritos e legíveis por humanos.
Há uma exceção, no entanto: caso você tenha em mãos headers deploráveis como os das APIs da M$, talvez gastar seu tempo com a documentação "farta" e enterprise seja melhor do que perder sua sanidade tentando decifrar aquela sucata...
"utilizar a medida de exceção, e não de regra, que é ler os headers"
Os headers C foram criados em um tempo que não havia IDEs e seus navegadores de código ( pelo menos não para C, Lisp e Smalltalk é outra história ). Era também uma época em que não havia nem mesmo editores VIsuais. Comandos eram curtos pq era difícil para o programador ficar digitando longos comandos nos ttys da época, que também eram duros e resistentes ao toque.
Dessa forma, headers _eram_ A documentação.
Embora os tempos tenham mudado, ler a interface de um programa ou biblioteca através de seus headers só é visto como algo alienígena no mundinho Windows e para seus seguidores...
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Eu não disse isso. Eu estava dando uma justificativa a mais para você ter os headers como referência, já que eles necessariamente têm de estar atualizados. Mesmo com documentação farta e atualizada, ainda acho a referência pelos headers mais adequada para a programação, se você já conhece a biblioteca: isso pq não quero gastar meu tempo precioso lendo parágrafos e mais parágrafos de explicações sobre a arquitetura e funcionamento da biblioteca.
Os headers são a API de uma biblioteca, são sua documentação mínima de referência e devem ser bem escritos e legíveis por humanos.
Há uma exceção, no entanto: caso você tenha em mãos headers deploráveis como os das APIs da M$, talvez gastar seu tempo com a documentação "farta" e enterprise seja melhor do que perder sua sanidade tentando decifrar aquela sucata...
"utilizar a medida de exceção, e não de regra, que é ler os headers"
Os headers C foram criados em um tempo que não havia IDEs e seus navegadores de código ( pelo menos não para C, Lisp e Smalltalk é outra história ). Era também uma época em que não havia nem mesmo editores VIsuais. Comandos eram curtos pq era difícil para o programador ficar digitando longos comandos nos ttys da época, que também eram duros e resistentes ao toque.
Dessa forma, headers _eram_ A documentação.
Embora os tempos tenham mudado, ler a interface de um programa ou biblioteca através de seus headers só é visto como algo alienígena no mundinho Windows e para seus seguidores...
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Comentário de Ananias
12/11/05 19:35 - usuário registrado #444
Do jeito que você fala...: ... parece que para descobrir o que um programa faz você olha o código fonte, ao invés de ler a página do manual.
Imagino a conversa:
Usuário: Pessoal, como eu faço para o comando ls retornar o tamanho dos arquivos?
nemesis: seu idiota, abra o código-fonte do ls, procura por getopt, provavelmente vai ter um switch para percorrer todas as opções possíveis. Siga cada case, e você vai descobrir como fazer o que você quer...
Nemesis, acho que na ânsia de me criticar, você não percebe as posições ridículas que você acaba assumindo. Nesse momento, você está defendendo que a fonte primária de documentação são os headers, e não a documentação propriamente dita. Você deve achar que as pessoas resolveram chamar a documentação de "documentação" por ironia, ou algo assim, já que na verdade quem documenta são os cabeçalhos e os códigos-fonte. (já que você está substituindo meu corretor ortográfico, acertei o plural? Ou é códigos-fontes?)
--
http://br-linux.blogspot.com
Não é tira-teima de nada, mas é interessante
Imagino a conversa:
Usuário: Pessoal, como eu faço para o comando ls retornar o tamanho dos arquivos?
nemesis: seu idiota, abra o código-fonte do ls, procura por getopt, provavelmente vai ter um switch para percorrer todas as opções possíveis. Siga cada case, e você vai descobrir como fazer o que você quer...
Nemesis, acho que na ânsia de me criticar, você não percebe as posições ridículas que você acaba assumindo. Nesse momento, você está defendendo que a fonte primária de documentação são os headers, e não a documentação propriamente dita. Você deve achar que as pessoas resolveram chamar a documentação de "documentação" por ironia, ou algo assim, já que na verdade quem documenta são os cabeçalhos e os códigos-fonte. (já que você está substituindo meu corretor ortográfico, acertei o plural? Ou é códigos-fontes?)
--
http://br-linux.blogspot.com
Não é tira-teima de nada, mas é interessante
Comentário de CWagner
13/11/05 5:03 - usuário registrado #49
Troll-mor, existem vários ti: Troll-mor, existem vários tipos de usuários. Você bem sabe disso, mas vou fazer de conta que você é o idiota que tenta mostrar ser.
Para usuários-finais, pseudo amebas, que sequer sabem onde ficam os botões do mouse, um tutorial, apostila e outras formas de literatura, ou quem sabe alguém que deveria passar mais tempo ajudando aos outros que ficar trollando em blogs na Internet (estou falando de você, Ananias).
Para usuários intermedíarios, páginas man e info, alguns how-tos e voilá, você tem tudo que precisa saber sobre comandos e programas.
Para administradores de sistemas e redes, as infinitas linhas de manuais, que explicam como funciona cada opção de linha de comando ou parâmetro de configuração de um .conf.
Para PROGRAMADORES, um .h bem documentado, como reza a cartilha de programação mais básica da face da Terra, onde vivem os que acham que valem à pena algumas regras mínimas de convivência.
Mas para pessoas como você não basta nada disso, pois tudo é motivo para crítica, retórica e falácia.
Vai procurar uma mulher, meu caro... computador demais, quando "sobe pra cabeça", dificilmente tem jeito... toma cuidado, ou vergonha, ou seja lá o que for e procura viver a tua vida, MALA.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Carlos Wagner - São Luís / MA
Para usuários-finais, pseudo amebas, que sequer sabem onde ficam os botões do mouse, um tutorial, apostila e outras formas de literatura, ou quem sabe alguém que deveria passar mais tempo ajudando aos outros que ficar trollando em blogs na Internet (estou falando de você, Ananias).
Para usuários intermedíarios, páginas man e info, alguns how-tos e voilá, você tem tudo que precisa saber sobre comandos e programas.
Para administradores de sistemas e redes, as infinitas linhas de manuais, que explicam como funciona cada opção de linha de comando ou parâmetro de configuração de um .conf.
Para PROGRAMADORES, um .h bem documentado, como reza a cartilha de programação mais básica da face da Terra, onde vivem os que acham que valem à pena algumas regras mínimas de convivência.
Mas para pessoas como você não basta nada disso, pois tudo é motivo para crítica, retórica e falácia.
Vai procurar uma mulher, meu caro... computador demais, quando "sobe pra cabeça", dificilmente tem jeito... toma cuidado, ou vergonha, ou seja lá o que for e procura viver a tua vida, MALA.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Carlos Wagner - São Luís / MA
Comentário de Ananias
13/11/05 14:47 - usuário registrado #444
Ah, sim: ara PROGRAMADORES, um .h bem documentado, como reza a cartilha de programação mais básica da face da Terra
Então eu fico me perguntando: por que, ora por que, os desenvolvedores escrevem documentação (de verdade) descrevendo as APIs? E não são só as MS... são os do Gnome, do KDE, do Kernel, etc...
Será, oh será, que o cara que escreve o manual da API do Gnome, mostrando quais são os argumentos da gtk_dialog_new_with_buttons, está pensando nos usuáriso finais? Nos intermediários? Nos administradores? Ou, nos programadores? Adivinha...
Mesmo para os programadores, acredite, existe documentação, e, por mais incrível que pareça, ela é a fonte primária de documentação. (Que coincidência!)
Eu concordo com o nemesis, que em alguns projetos, notadamente nos projetos voluntários, a documentação é parca, inexistente, incompleta e, quando existe, inútil. Nesses casos, a documentação deixa de ser a fonte de informação, eu concordo.
Quando existe documentação, a documentação deve ser utilizada como fonte de documentação. Isso é tão óbvio, que eu me sinto com vergonha de ter que explicar.
Se você diz que pros PROGRAMADORES, com letras maiúsculas, um .h deve ser a documentção mais básica - e essencial, suponho, por que, oh por que, a grande maioria dos projetos de bibliotecas escrevem documentações?
--
http://br-linux.blogspot.com
Não é tira-teima de nada, mas é interessante
Então eu fico me perguntando: por que, ora por que, os desenvolvedores escrevem documentação (de verdade) descrevendo as APIs? E não são só as MS... são os do Gnome, do KDE, do Kernel, etc...
Será, oh será, que o cara que escreve o manual da API do Gnome, mostrando quais são os argumentos da gtk_dialog_new_with_buttons, está pensando nos usuáriso finais? Nos intermediários? Nos administradores? Ou, nos programadores? Adivinha...
Mesmo para os programadores, acredite, existe documentação, e, por mais incrível que pareça, ela é a fonte primária de documentação. (Que coincidência!)
Eu concordo com o nemesis, que em alguns projetos, notadamente nos projetos voluntários, a documentação é parca, inexistente, incompleta e, quando existe, inútil. Nesses casos, a documentação deixa de ser a fonte de informação, eu concordo.
Quando existe documentação, a documentação deve ser utilizada como fonte de documentação. Isso é tão óbvio, que eu me sinto com vergonha de ter que explicar.
Se você diz que pros PROGRAMADORES, com letras maiúsculas, um .h deve ser a documentção mais básica - e essencial, suponho, por que, oh por que, a grande maioria dos projetos de bibliotecas escrevem documentações?
--
http://br-linux.blogspot.com
Não é tira-teima de nada, mas é interessante
Comentário de nemesis
13/11/05 19:24 - usuário registrado #1514
skol: Ainda bem que estou de bom humor, aqui ao lado de minha loira gelada... :)
"você não percebe as posições ridículas que você acaba assumindo. Nesse momento, você está defendendo que a fonte primária de documentação são os headers"
Exatamente. O que tem de ridículo nisso, afinal? Uma listagem me mostrando assinaturas de funções e tipos de dados usados. Se os nomes usados para os tipos de dados, as funções e seus parâmetros forem significativos, isso basta. Senão, realmente vou precisar de um mapa para me encontrar. Que é exatamente o que muitos propõem com "documentação farta".
"ora por que, os desenvolvedores escrevem documentação (de verdade) descrevendo as APIs?"
Isso é mero formalismo, histórico ou justificativa para custos etc. Projetos precisam ser explicados, principalmente para maus entendedores. Para bons entendedores, headers bastam.
Sério, cara, eu gostaria que a documentação de empresas como Microsoft ou Oracle fosse menos "farta", com menos "gordura", e por "gordura" não quero dizer que eles deveriam documentar apenas pela metade, aleatoriamente. Não, quero dizer que deveriam: ou escrever APIs mais sensatas, para que não fosse necessária tanta explicação; ou pelo menos, reduzir a própria verbosidade e marketing sempre presentes pelo menos nos parágrafos iniciais e finais de cada página.
Enfim, o que eu gostaria de uma documentação de referência:
* uma listagem com os tipos de dados definidos para uso
* uma listagem com as funções, seus tipos de retorno e os tipos e nomes de seus parâmetros
* uma listagem de eventuais variáveis globais e constantes.
ops! parece que acabei de descrever um header! e eles ainda vêm prefixados por comentários excelentes ou bem-humorados... :D
Bom, fico por aí. vou descer a loira em minha goela em sua homenagem, Ananias O'Troll... :))
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
"você não percebe as posições ridículas que você acaba assumindo. Nesse momento, você está defendendo que a fonte primária de documentação são os headers"
Exatamente. O que tem de ridículo nisso, afinal? Uma listagem me mostrando assinaturas de funções e tipos de dados usados. Se os nomes usados para os tipos de dados, as funções e seus parâmetros forem significativos, isso basta. Senão, realmente vou precisar de um mapa para me encontrar. Que é exatamente o que muitos propõem com "documentação farta".
"ora por que, os desenvolvedores escrevem documentação (de verdade) descrevendo as APIs?"
Isso é mero formalismo, histórico ou justificativa para custos etc. Projetos precisam ser explicados, principalmente para maus entendedores. Para bons entendedores, headers bastam.
Sério, cara, eu gostaria que a documentação de empresas como Microsoft ou Oracle fosse menos "farta", com menos "gordura", e por "gordura" não quero dizer que eles deveriam documentar apenas pela metade, aleatoriamente. Não, quero dizer que deveriam: ou escrever APIs mais sensatas, para que não fosse necessária tanta explicação; ou pelo menos, reduzir a própria verbosidade e marketing sempre presentes pelo menos nos parágrafos iniciais e finais de cada página.
Enfim, o que eu gostaria de uma documentação de referência:
* uma listagem com os tipos de dados definidos para uso
* uma listagem com as funções, seus tipos de retorno e os tipos e nomes de seus parâmetros
* uma listagem de eventuais variáveis globais e constantes.
ops! parece que acabei de descrever um header! e eles ainda vêm prefixados por comentários excelentes ou bem-humorados... :D
Bom, fico por aí. vou descer a loira em minha goela em sua homenagem, Ananias O'Troll... :))
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Comentário de Patola
14/11/05 17:06 - usuário registrado #184
Tocou no ponto certo: DADOS: Os headers descrevem os dados; os dados são, em geral, a parte mais importante da aplicação, e em volta dos quais a aplicação deve ser construída (e não o contrário).
Nos headers têm a estrutura dos dados e o nome das chamadas/métodos; isso é o mais importante. Documentação do estilo do Ananias, descrevendo o que a função faz mais verbosamente e como usá-la, assim como uma descrição mais prolixa dos dados, vem depois, principalmente se você está usando como referência.
--
LinuxFUD, o TIRA-TEIMA dos ataques ao software livre: http://linuxfud.org
Nos headers têm a estrutura dos dados e o nome das chamadas/métodos; isso é o mais importante. Documentação do estilo do Ananias, descrevendo o que a função faz mais verbosamente e como usá-la, assim como uma descrição mais prolixa dos dados, vem depois, principalmente se você está usando como referência.
--
LinuxFUD, o TIRA-TEIMA dos ataques ao software livre: http://linuxfud.org
Comentário de nemesis
14/11/05 18:12 - usuário registrado #1514
heh: putz, não quero parecer o Ananias, mas vou ter que discordar...
Dados são importantes no sentido de que se não fosse para acessá-los e manipulá-los de alguma forma, não haveria a necessidade de automatizar essa tarefa com a Informática. No entanto...
No entanto, sem funções, não há sistema! Se você só tem dados, isso significa que vc tem um punhado de modelos, especificações, diagramas e regras de negócio descrevendo como os dados se relacionam. Isso não é o sistema: é o que os analistas de sistemas entregam para os programadores para efetivamente termos um sistema.
Automatização, processamento necessariamente denotam ação. Dados são passivos, funções, ativos. Não importa o quanto o pessoal OO chie: o que realmente faz um sistema são funções/procedimentos/subrotinas/métodos ou o que você preferir chamá-los...
E por isso gosto da concisão dos headers ao mostrar todas essas informações realmente úteis sobre a interface do sistema. Como referência, é imprescindível. Se eu quisesse ser doutrinado sobre o quão soberbo é o framework que estou usando, leria a extensa e detalhada documentação...
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Dados são importantes no sentido de que se não fosse para acessá-los e manipulá-los de alguma forma, não haveria a necessidade de automatizar essa tarefa com a Informática. No entanto...
No entanto, sem funções, não há sistema! Se você só tem dados, isso significa que vc tem um punhado de modelos, especificações, diagramas e regras de negócio descrevendo como os dados se relacionam. Isso não é o sistema: é o que os analistas de sistemas entregam para os programadores para efetivamente termos um sistema.
Automatização, processamento necessariamente denotam ação. Dados são passivos, funções, ativos. Não importa o quanto o pessoal OO chie: o que realmente faz um sistema são funções/procedimentos/subrotinas/métodos ou o que você preferir chamá-los...
E por isso gosto da concisão dos headers ao mostrar todas essas informações realmente úteis sobre a interface do sistema. Como referência, é imprescindível. Se eu quisesse ser doutrinado sobre o quão soberbo é o framework que estou usando, leria a extensa e detalhada documentação...
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Comentário de Patola
14/11/05 19:23 - usuário registrado #184
Your mileage may vary: Isso é apenas um dos mantras que muito ouvia na faculdade: os dados são mais importantes que o código. Mas tem algo que eu aprendi fora da faculdade, que os mais profundos mantras da computação são quebrados com facilidade (taí o Linux com seus super-goto's que deixariam o Dijkstra apavorado).
Na minha experiência até agora esse mantra tem sido verdadeiro. Os dados assumem o papel principal na aplicação. Talvez seja o tipo de aplicação que eu faço. Talvez na programação específica a que você se dedica, eles não assumam um papel tão central.
--
LinuxFUD, o TIRA-TEIMA dos ataques ao software livre: http://linuxfud.org
Na minha experiência até agora esse mantra tem sido verdadeiro. Os dados assumem o papel principal na aplicação. Talvez seja o tipo de aplicação que eu faço. Talvez na programação específica a que você se dedica, eles não assumam um papel tão central.
--
LinuxFUD, o TIRA-TEIMA dos ataques ao software livre: http://linuxfud.org
Comentário de CWagner
15/11/05 4:02 - usuário registrado #49
Inventar um mega-super-hiper-: Inventar um mega-super-hiper-ultra-duca algoritmo que processa e/ou armazena: NADA.
Assim até o Papai Noel, com a ajuda do Coelhinho da Páscoa faz um programa... (com todos os sentidos que a frase permitir).
Dizer que os dados são menos importantes me faz lembrar de uma cláusula da EULA: "Não nos responsabilizamos por nada que aconteça com seus dados".
Parece que alguém por aqui anda com uma cópia colada no travesseiro, para não dar importância aos dados. Como a M$ faz com a maioria dos apolicativos dela: "Afinal de contas, pra que você queria mesmo aquele balanço anual da sua empresa que estava no sistema que rodava no último M$ S$QL $erver? Afinal de contas, os dados não são tão importantes assim :P"
Colocando em pratos limpos, cada papel no desenvolvimento de sistemas tem a sua importância e nenhuma é maior que a outra, e cada uma delas TEM que obrigatoriamente documentar muito bem a su parte, tendo em vista as diversas camadas no processo de desenvolvimento. Mais ou menos como o modelo OSI do TCP/IP.
Mas considerando com quem estamos tentando argumentar, ficaremos aqui, gastando impressões digitais à toa, mesmo porque a questão já foi muito bem dissecada por todos.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Carlos Wagner - São Luís / MA
Assim até o Papai Noel, com a ajuda do Coelhinho da Páscoa faz um programa... (com todos os sentidos que a frase permitir).
Dizer que os dados são menos importantes me faz lembrar de uma cláusula da EULA: "Não nos responsabilizamos por nada que aconteça com seus dados".
Parece que alguém por aqui anda com uma cópia colada no travesseiro, para não dar importância aos dados. Como a M$ faz com a maioria dos apolicativos dela: "Afinal de contas, pra que você queria mesmo aquele balanço anual da sua empresa que estava no sistema que rodava no último M$ S$QL $erver? Afinal de contas, os dados não são tão importantes assim :P"
Colocando em pratos limpos, cada papel no desenvolvimento de sistemas tem a sua importância e nenhuma é maior que a outra, e cada uma delas TEM que obrigatoriamente documentar muito bem a su parte, tendo em vista as diversas camadas no processo de desenvolvimento. Mais ou menos como o modelo OSI do TCP/IP.
Mas considerando com quem estamos tentando argumentar, ficaremos aqui, gastando impressões digitais à toa, mesmo porque a questão já foi muito bem dissecada por todos.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Carlos Wagner - São Luís / MA
Comentário de nemesis
16/11/05 13:04 - usuário registrado #1514
fora-do-ar: fala, cambada!
Fiquei fora do ar pq parece que meu micro doméstico resolveu passar desta para a melhor (ferro-velho) de vez. Vou tomar vergonha e comprar um novo...
agora, aos fatos:
Patola:
"Isso é apenas um dos mantras que muito ouvia na faculdade: os dados são mais importantes que o código."
Sim, também ouvi muito esse mantra. Juntamente com a doutrinação "orientação-a-objetos é o futuro"... é só uma reza braba... :)
"(taí o Linux com seus super-goto's que deixariam o Dijkstra apavorado)."
Ou a M$ continuando a longa tradição de criação de retardados com BASIC...
CWagner:
"Inventar um mega-super-hiper-ultra-duca algoritmo que processa e/ou armazena: NADA."
Que eu saiba, um algoritmo só é caracterizado por sua saída. Um algoritmo não precisa necessariamente tem entradas, mas se não tiver saída -- um resultado, digamos, o armazentamento de informações em um banco de dados ou impressão de texto em um terminal -- então é o mesmo que nada. Também é um dos mantras que ouvi na faculdade...
Um exemplo de algoritmo que não recebe nada de entrada, apenas produz resultados: um gerador de padrões aleatórios, como um screensaver...
Patola:
"Os dados assumem o papel principal na aplicação."
CWagner:
"Dizer que os dados são menos importantes me faz lembrar de uma cláusula da EULA: 'Não nos responsabilizamos por nada que aconteça com seus dados'."
É central, para o usuário, sim. Ok, digamos que dados e funções se complementam. Embora eu acredite que funções são mais importantes dentro da Informática.
Isso porque, sem funções, não há Informática, não há processamento de dados de forma automática: o usuário que se vire com seus dados em pilhas de papéis, como era antigamente. Por outro lado, pela própria definição de algoritmo e o exemplo que dei, funções ( algoritmos ) não precisam de dados de entrada para terem existência própria e realizarem sua função.
Informática sem dados é possível, sem funções/algoritmos, não. O "automática" é mais primordial do que a "informação"...
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Fiquei fora do ar pq parece que meu micro doméstico resolveu passar desta para a melhor (ferro-velho) de vez. Vou tomar vergonha e comprar um novo...
agora, aos fatos:
Patola:
"Isso é apenas um dos mantras que muito ouvia na faculdade: os dados são mais importantes que o código."
Sim, também ouvi muito esse mantra. Juntamente com a doutrinação "orientação-a-objetos é o futuro"... é só uma reza braba... :)
"(taí o Linux com seus super-goto's que deixariam o Dijkstra apavorado)."
Ou a M$ continuando a longa tradição de criação de retardados com BASIC...
CWagner:
"Inventar um mega-super-hiper-ultra-duca algoritmo que processa e/ou armazena: NADA."
Que eu saiba, um algoritmo só é caracterizado por sua saída. Um algoritmo não precisa necessariamente tem entradas, mas se não tiver saída -- um resultado, digamos, o armazentamento de informações em um banco de dados ou impressão de texto em um terminal -- então é o mesmo que nada. Também é um dos mantras que ouvi na faculdade...
Um exemplo de algoritmo que não recebe nada de entrada, apenas produz resultados: um gerador de padrões aleatórios, como um screensaver...
Patola:
"Os dados assumem o papel principal na aplicação."
CWagner:
"Dizer que os dados são menos importantes me faz lembrar de uma cláusula da EULA: 'Não nos responsabilizamos por nada que aconteça com seus dados'."
É central, para o usuário, sim. Ok, digamos que dados e funções se complementam. Embora eu acredite que funções são mais importantes dentro da Informática.
Isso porque, sem funções, não há Informática, não há processamento de dados de forma automática: o usuário que se vire com seus dados em pilhas de papéis, como era antigamente. Por outro lado, pela própria definição de algoritmo e o exemplo que dei, funções ( algoritmos ) não precisam de dados de entrada para terem existência própria e realizarem sua função.
Informática sem dados é possível, sem funções/algoritmos, não. O "automática" é mais primordial do que a "informação"...
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
como transações, funções, gatilhos e subconsultas, o PostgreSQL é utilizado por várias empresas e agências do governo.
De quem foi a idéia de traduzir termos como "triggers"? Será que ele suporta os comandos "selecionar" e "inserir"?
--
http://br-linux.blogspot.com
Não é tira-teima de nada, mas é interessante