No último dia 6, o PostgreSQL Global Development Group anunciou o provável último beta da versão 9.0 do servidor de banco de dados open source mais avançado do mundo. A previsão oficial é até o mês de setembro deste ano, mas alguns acreditam que a versão final saia do forno ainda neste mês.
Como não poderia deixar de ser, nós da Especializa acompanhamos sem piscar os olhos e já estamos preparando nossos cursos para tão logo possamos considerar as novidades definitivas.
Vejamos o que virá de tão bom a ponto da versão haver mudado de número (inicialmente, seria 8.5).
A versão 8 do PostgreSQL foi um marco histórico bastante importante para este SGBD. Talvez a principal razão tenha sido o tão esperado suporte nativo a sistemas de arquivos NTFS e, consequentemente, a capacidade de rodar em ambientes Windows.
Apesar do mundo Unix dominar largamente os servidores que rodam o PostgreSQL, mesmo após a oitava versão, suportar nativamente o Windows, foi um passo importante na busca pela popularização de um banco sempre considerado robusto, mas pouco atraente em termos de facilidade de administração.
O raciocínio é óbvio. Mais gente utilizando traz naturalmente mais gente disposta a desenvolver ferramentas para melhorar o dia-a-dia de quem utiliza.
Após quatro rodadas de atualizações da versão 8, que apesar de minor realeases (incremento do número após o ponto, 8.1, 8.2, 8.3 e 8.4), evoluíram consideravelmente o PostgreSQL em diversas áreas, estava claro que lançar uma versão 9 certamente significaria uma responsabilidade muito grande. Mesmo assim, a comunidade open source achou que o que eles estavam trabalhando não poderia ser apenas um 8.5.
Acredito que estamos tratando de um SGBD maduro que provavelmente será difícil encontrar alguma new feature que por si só já o transporte a uma nova versão. O motivo para chamar o PostgreSQL de 9.0 agora foi a quantidade de melhorias implementadas pela comunidade. Só para se ter uma idéia, foram catalogados 84 desenvolvedores produzindo mais de 200 melhorias e correções nesta versão.
Um ponto positivo para o PostgreSQL é a descentralização de desenvolvedores, sendo possível notar que muitos dos principais colaboradores do núcleo do sistema trabalham numa gama bem variada de empresas. Isto de certa forma potencializa a garantia de que os planos não serão mudados de uma hora pra outra.
É, estou sim me referindo à celeuma envolvendo o MySQL quando a Oracle adquiriu a Sun e provocou dissidências como o MariaDB e algumas incertezas quanto ao seu futuro. Ingenuamente, podemos pensar “ah, o MySQL não é open source? Então se a Oracle quiser matá-lo a comunidade vem e cria um fork dele” (calma que não foi bem isso que ela anunciou que faria).
Tudo bem, existem diversos exemplos de forks na comunidade que alcançaram sucesso igual ou maior que seu progenitor (sem ir muito longe, o próprio Firebird nasceu da abertura do fonte do Interbase da Borland). Mas a realidade não é tão simples. Muitas vezes, optar por um concorrente próximo quando seu produto open source favorito parece um tanto “sem futuro” é a solução mais rápida e indolor. E aí, quando a comunidade amadurecer o fork recém nascido, já era! A própria comunidade talvez já tenha abandonado a criança.
Por outro lado, essa pulverização de empresas e profissionais contribuidores pode refletir em uma falta de personalidade própria, se é que posso chamar assim. Em outras palavras, um gestor de TI ao refletir sobre utilizar ou não o PostgreSQL em seus servidores pode se questionar: Quem está por trás dele? Quem garante que ele vai atender às minhas necessidades? E quem é a pessoa mais indicada para me informar qual a maneira ideal de adaptar o PostgreSQL à minha realidade? Neste momento, os “quens” certamente serão preenchidos por empresas que talvez ele nunca tenha ouvido falar.
Por isso, o fortalecimento de empresas como a EnterpriseDB (praticamente o Quem por trás hoje), a Command Prompt e a própria PostgreSQL Experts encabeçada por Josh Berkus pode ser saudável. Some a elas as presenças de gigantes como Sun (Oracle), Red Hat e Google, todas estas com major contributors focados no PostgreSQL, para garantir de que se a EnterpriseDB um dia for comprada pela Microsoft (só para dar um exemplo mais dramático) ela não terá como simplesmente matar o PostgreSQL.
O nosso ponto de partida no estudo das novidades é o Wiki oficial, mais especificamente no endereço:
http://wiki.postgresql.org/wiki/Development_information. Lá você encontrará diversas informações e links interessantes como a Feature Matrix apresentando o que vem sendo implentando desde a versão 7.4
Robert Treat, da OmniTI e major contributor do PostgreSQL, elenca em sua palestra melhorias em performance, administração, desenvolvimento e procedimentos. Podemos destacar:
-
Ordered aggregates
Dados podem ser previamente ordenados antes de serem fornecido a alguma função de agregação. Este link trata do assunto usando array_agg().
-
Window functions
Na verdade elas já existiam desde o PostgreSQL 8.4 (você pode conferir na Feature Matrix), mas agora novas funcionalidades para elas foram criadas. Este link introduz o assunto, abordando as cláusulas PARTITION e WINDOW. Já este link faz um comparativo do suporte a essa funcionalidade, parte do padrão ANSI SQL 2003, no PostgreSQL 8.4 com o SQL Server 2008, Oracle e DB2.
Aqui, você pode encontrar algo sobre o que há de novo no 9.0 dentro deste assunto.
-
Join removal
O planejador de consultas do PostgreSQL pode excluir do plano tabelas que não são necessárias para obtenção dos dados resultantes. Leia mais, aqui.
-
Explain buffers
O comando explain agora exibe também as páginas de dados envolvidas em consultas. Buffers são unidades normalmente de 8kb que armazenam os dados de fato.
-
Grant em esquema
Comandos Grant e Revoke podem ser aplicados a esquemas. Confira.
-
Suporte a Windows de 64 bits
-
Initdb chamado via pg_ctl
O executável postgres já era chamado via pg_ctl, agora o initdb também poderá ser.
-
Triggers condicionais
Triggers agora contam com a cláusula WHEN para avaliar uma expressão boleana e decidir se devem ou não ser disparada.
-
PL/pgSQL
A linguagem procedural mais utilizada no PostgreSQL já vem instalada nativamente. Claro que você poderia realizar um CREATE LANGUAGE plpgsql; em template1 que tava tudo resolvido. Também houve melhorias na sintaxe da linguagem.
-
Hot Standby
O tão esperado recurso de replicação que viria no 8.4, agora veio.
-
Streaming replication
Mais um recurso interessante para replicações. Confira mais aqui.
-
pg_upgrade
Ferramenta para facilitar o processo de upgrade de versão de um cluster PostgreSQL.
Há ainda diversas outras melhorias.
Fica a promessa aqui de escrever algum tutorial explicando algumas delas.
CREATE LANGUAGE plpgsql;