A Oracle comprou a SUN e conseqüentemente o Java e o MySQL. Mais informações podem ser obtidas aqui. Que impactos esta aquisição causará sobre o PostgreSQL?
Ainda é muito cedo para ter certezas sobre este tema, mas ele certamente é bastante crítico para a área de banco de dados. A Oracle adquiriu nos últimos anos uma série de empresas e seus softwares de banco, dentre elas o Berkeley DB, que passaram a figurar entre as soluções desta empresa. As novas aquisições continuarão a ser livres e a serem aprimoradas? O suporte do java ao PostgreSQL estará ameaçado? O espaço para o PostgreSQL diminuirá ou será ampliado? Estas e outras questões permanecem em aberto.
Baseado nestas dúvidas tive a idéia de criar um tópico aberto. Peço que coloquem opiniões e links para reportagens sobre o impacto desta aquisição para a comunidade de banco de dados e particularmente para os usuários do PostgreSQL.
Atualização (13/05/2009): anexo link para posts sobre o assunto no site do Fernando Ike e do Telles.
No ar desde 2007! Blog com informações e notícias sobre o banco de dados PostgreSQL, aquele que todos adoramos usar. Trata-se de uma ferramenta livre e de código aberto, mantida por uma comunidade ativa de usuários da qual você é convidado fazer parte. Textos, ideias e outras contribuições podem ser enviadas para Cláudio Bezerra Leopoldino: claudiob_br@yahoo.com.br
terça-feira, 28 de abril de 2009
quinta-feira, 16 de abril de 2009
Versão 8.4: primeira release beta disponível!
O grupo de desenvolvimento do PostgreSQL anunciou que a primeira versão 8.4 BETA está disponível para download. A colaboração da comunidade nos testes é de vital importância para o diagnóstico e correção de quaisquer problemas na ferramenta. Esta versão não deve ser utilizada para aplicações corporativas, por ser menos estável que as releases padrão.
Testemos, critiquemos e participemos!!!
Mais informações em: http://www.postgresql.org/developer/beta.
Em breve apresentaremos um detalhamento das novas funcionalidades da versão 8.4 neste espaço.
Testemos, critiquemos e participemos!!!
Mais informações em: http://www.postgresql.org/developer/beta.
Em breve apresentaremos um detalhamento das novas funcionalidades da versão 8.4 neste espaço.
quarta-feira, 8 de abril de 2009
Fique Atualizado em PostgreSQL com o Addict-o-matic!!!
Ficar atualizado em tecnologias de hardware e software não é das tarefas mais fáceis. O site Addict-o-matic faz a coleta de uma série de notícias, posts em blogs, vídeos e imagens em uma série de fontes na rede. O resultado de uma pesquisa sobre o PostgreSQL não decepcionou.
Clique aqui para experimentar! Podem ser fornecidas várias opções de pesquisa, e o site funciona bem como agregador de informações.
A dica do site foi do blog da colunista Sandra Carvalho.
Clique aqui para experimentar! Podem ser fornecidas várias opções de pesquisa, e o site funciona bem como agregador de informações.
A dica do site foi do blog da colunista Sandra Carvalho.
sexta-feira, 3 de abril de 2009
Ano Bissexto no PostgreSQL!
Às vezes o mais difícil de fazer são coisas realmente simples. Os exemplo de código abaixo são implementações de uma rotina que calcula se um ano é bissexto ou não.
Segundo a Wikipedia, as regras do ano bissexto são poucas, mas não são triviais:
* São bissextos todos os anos múltiplos de 400, p.ex: 1600, 2000, 2400, 2800
* Não são bissextos todos os múltiplos de 100 e não de 400, p.ex: 1700, 1800, 1900, 2100, 2200, 2300, 2500...
* São bissextos todos os múltiplos de 4 e não múltiplos de 100, p.ex: 1996, 2004, 2008, 2012, 2016...
* Não são bissextos todos os demais anos.
Com base no que é apresentado neste post, peço que você que me responda três perguntas:
- Os dois exemplos abaixo estão corretos?
- Qual dos dois apresentaria alguma vantagem em relação ao outro? Ou são ambos equivalentes?
- É possível melhorar as implementações? De que formas?
As duas funções criadas retornam 1 se ano for bissexto, 0 se não for e 99 se for anterior a 1582, para anos acima de 1582.
Exemplo 1:
CREATE OR REPLACE FUNCTION ano_bissexto (pAno integer) RETURNS integer AS $$
DECLARE
ret integer;
BEGIN
IF $1<1582 THEN RETURN 99; END IF;
ret :=0; --Inicialização
IF ($1%400=0) THEN
ret:=1; /*Bissexto*/
ELSE
IF ($1%4=0) AND ($1%100<>0) THEN
ret:=1; /*Bissexto*/
END IF;
END IF;
RETURN ret;
END;
$$ LANGUAGE plpgsql;
SELECT ano_bissexto(1600);
Exemplo 2:
CREATE OR REPLACE FUNCTION ano_bissexto_menor (pAno integer) RETURNS integer AS $$
DECLARE
ret integer;
BEGIN
IF $1<1582 THEN RETURN 99; END IF;
ret :=$1; --Inicialização
IF (ret%100=0) THEN
ret:=ret/100;
END IF;
IF ret%4=0 THEN
RETURN 1; --Bissexto
ELSE
RETURN 0;
END IF;
END;
$$ LANGUAGE plpgsql;
SELECT ano_bissexto_menor(1600);
Segundo a Wikipedia, as regras do ano bissexto são poucas, mas não são triviais:
* São bissextos todos os anos múltiplos de 400, p.ex: 1600, 2000, 2400, 2800
* Não são bissextos todos os múltiplos de 100 e não de 400, p.ex: 1700, 1800, 1900, 2100, 2200, 2300, 2500...
* São bissextos todos os múltiplos de 4 e não múltiplos de 100, p.ex: 1996, 2004, 2008, 2012, 2016...
* Não são bissextos todos os demais anos.
Com base no que é apresentado neste post, peço que você que me responda três perguntas:
- Os dois exemplos abaixo estão corretos?
- Qual dos dois apresentaria alguma vantagem em relação ao outro? Ou são ambos equivalentes?
- É possível melhorar as implementações? De que formas?
As duas funções criadas retornam 1 se ano for bissexto, 0 se não for e 99 se for anterior a 1582, para anos acima de 1582.
Exemplo 1:
CREATE OR REPLACE FUNCTION ano_bissexto (pAno integer) RETURNS integer AS $$
DECLARE
ret integer;
BEGIN
IF $1<1582 THEN RETURN 99; END IF;
ret :=0; --Inicialização
IF ($1%400=0) THEN
ret:=1; /*Bissexto*/
ELSE
IF ($1%4=0) AND ($1%100<>0) THEN
ret:=1; /*Bissexto*/
END IF;
END IF;
RETURN ret;
END;
$$ LANGUAGE plpgsql;
SELECT ano_bissexto(1600);
Exemplo 2:
CREATE OR REPLACE FUNCTION ano_bissexto_menor (pAno integer) RETURNS integer AS $$
DECLARE
ret integer;
BEGIN
IF $1<1582 THEN RETURN 99; END IF;
ret :=$1; --Inicialização
IF (ret%100=0) THEN
ret:=ret/100;
END IF;
IF ret%4=0 THEN
RETURN 1; --Bissexto
ELSE
RETURN 0;
END IF;
END;
$$ LANGUAGE plpgsql;
SELECT ano_bissexto_menor(1600);
quinta-feira, 2 de abril de 2009
Enquete Encerrada: PostgreSQL é um Ótimo Nome para Banco de Dados!
A enquete que perguntava a respeito do nome do PostgreSQL foi encerrada, e foi considerado que o nome tradicional deve ser mantido por uma maioria esmagadora. Os nomes alternativos sugeridos não tiveram aceitação e a opção de outros nomes não foi acolhida. Abaixo, os dados:
Opção | Votos | Percentual |
Deve ser mantido. | 152 | 69,72 |
Que tal PgDB? | 15 | 6,88 |
Postgree seria melhor | 35 | 16,06 |
Outro | 9 | 4,13 |
Não sei. | 7 | 3,21 |
Totais | 218 | 100 |
Concorda com o resultado? Discorda? Deixe seu comentário!
Assinar:
Postagens (Atom)