Estão disponíveis os betas de instaladores para Linux e Mac que permite a instalação com apenas "um clique". A criação destes instaladores foi feita péla equipe do EnterpriseDB. Espera-se que a dificuldade de instalação nestas plataformas seja minimizada.
Os instaladores contém o PostgreSQL 8.3.3 com pgAdmin 1.8.4, pl/Java e o plugin para debug da linguagem pl/pgsql.
O download pode ser feito em:
Linux 32 e 64 bits: http://www.postgresql.org/download/linux
Mac OS X 10.4: http://www.postgresql.org/download/macosx
sexta-feira, 18 de julho de 2008
quarta-feira, 9 de julho de 2008
PostgreSQL: Presença Fraca no Youtube
A presença do PostgreSQL entre os grandes SGBDs pode ser medida de diversas formas. Em busca de vídeos interessantes de PostgreSQL, fiz uma busca no Youtube, e me decepcionei. Encontrei apenas 356 vídeos. É muito pouco para cobrir todas as funcionalidades e possibilidades deste banco de dados.
Considerando-se que este resultado envolve todos os idiomas, os resultados são ainda mais fracos, pois temos muito pouca coisa em Português. A qualidade da imagem também deixa a desejar, possivelmente pelo formato do Youtube, que reduz a resolução e prejudica apresentações que capturam telas do computador e as filmagens de apresentações em telões multimídia. Faltam comentários nos vídeos, a visualização ainda é pequena por parte da comunidade e muitos permanecem sem avaliação (o Youtube tem uma graduação que vai até 5 estrelas). Vi bons vídeos em italiano, mas acho que a estrada a ser trilhada pelo PostgreSQL em vídeo ainda está no seu início.
Para ter uma visão comparativa, fiz outras buscas para outros SGBDs. Entre os bancos de dados livres, apesar do PostgreSQL só estar atrás do MySQL, não se pode dizer que é uma boa colocação. A abrangência, quantidade e qualidade dos vídeos pode melhorar muito. O próprio campeão MySQL teve muito mais resultados encontrados, mas bem abaixo do que poderia ser. O fato é que ainda não utilizamos vídeos como forma de aprendizado e divulgação de conhecimento como poderíamos.
Mesmo os Bancos de Dados proprietários apresentam poucas opções, mas o SQL Server teve quase o dobro de vídeos que o PostgreSQL. O Oracle também decepcionou e pode ser alcançado pelo PostgreSQL com algum trabalho da comuindade.
O ranking total aparece abaixo. Faltam alguns SGBDs, mas o propósito não era uma busca exaustiva. A grande surpresa foi o DB2, com a terceira colocação. Os bancos de dados livres lideram com o MySQL e o PostgreSQL ocupa apenas uma posição intermediária, com o quinto lugar.
1 - MySQL: 1330
2 - SQL Server: 674
3 - IBM DB2: 461
4 - Oracle (busca por "Oracle SQL"): 406
5 -PostgreSQL: 356
6 - Firebird (busca por "Firebird SQL"): 171
7 - ACCESS (busca por "ACCESS SQL"): 50
8 - SQLite: 22
9 - ADABAS: 5
10 - HSQLDB: 0
O que podemos fazer a respeito?
Bom, creio que podemos influir positivamente quanto a esta questão:
- Assistir a vídeos de PostgreSQL no Youtube, dando feedback aos seus criadores, através de comentários e da colocação das estrelas, indicando os melhores. Esta ação permite que se possa estimular a produção de melhores vídeos e o reconhecimento dos autores.
- Postar novos fragmentos de palestras e de cursos com conteúdo novo e diversificados. Muitos eventos de Software Livre, de Banco de Dados em Geral e de PostgreSQL são gravados e poderia ser feita seleção e publicação de parte deste material.
- Produzir novos vídeos voltados para a internet. Podem ser pequenos, podem ser focados em temas específicos, indo do básico ao avançado. É a melhor forma de aprender a fazer mais e melhor.
Quem se habilita?
Este é um problema realmente grave?
Acredito que não, mas que é um ponto que pode ser melhor trabalhado pela comunidade do PostgreSQL.
Considerando-se que este resultado envolve todos os idiomas, os resultados são ainda mais fracos, pois temos muito pouca coisa em Português. A qualidade da imagem também deixa a desejar, possivelmente pelo formato do Youtube, que reduz a resolução e prejudica apresentações que capturam telas do computador e as filmagens de apresentações em telões multimídia. Faltam comentários nos vídeos, a visualização ainda é pequena por parte da comunidade e muitos permanecem sem avaliação (o Youtube tem uma graduação que vai até 5 estrelas). Vi bons vídeos em italiano, mas acho que a estrada a ser trilhada pelo PostgreSQL em vídeo ainda está no seu início.
Para ter uma visão comparativa, fiz outras buscas para outros SGBDs. Entre os bancos de dados livres, apesar do PostgreSQL só estar atrás do MySQL, não se pode dizer que é uma boa colocação. A abrangência, quantidade e qualidade dos vídeos pode melhorar muito. O próprio campeão MySQL teve muito mais resultados encontrados, mas bem abaixo do que poderia ser. O fato é que ainda não utilizamos vídeos como forma de aprendizado e divulgação de conhecimento como poderíamos.
Mesmo os Bancos de Dados proprietários apresentam poucas opções, mas o SQL Server teve quase o dobro de vídeos que o PostgreSQL. O Oracle também decepcionou e pode ser alcançado pelo PostgreSQL com algum trabalho da comuindade.
O ranking total aparece abaixo. Faltam alguns SGBDs, mas o propósito não era uma busca exaustiva. A grande surpresa foi o DB2, com a terceira colocação. Os bancos de dados livres lideram com o MySQL e o PostgreSQL ocupa apenas uma posição intermediária, com o quinto lugar.
1 - MySQL: 1330
2 - SQL Server: 674
3 - IBM DB2: 461
4 - Oracle (busca por "Oracle SQL"): 406
5 -PostgreSQL: 356
6 - Firebird (busca por "Firebird SQL"): 171
7 - ACCESS (busca por "ACCESS SQL"): 50
8 - SQLite: 22
9 - ADABAS: 5
10 - HSQLDB: 0
O que podemos fazer a respeito?
Bom, creio que podemos influir positivamente quanto a esta questão:
- Assistir a vídeos de PostgreSQL no Youtube, dando feedback aos seus criadores, através de comentários e da colocação das estrelas, indicando os melhores. Esta ação permite que se possa estimular a produção de melhores vídeos e o reconhecimento dos autores.
- Postar novos fragmentos de palestras e de cursos com conteúdo novo e diversificados. Muitos eventos de Software Livre, de Banco de Dados em Geral e de PostgreSQL são gravados e poderia ser feita seleção e publicação de parte deste material.
- Produzir novos vídeos voltados para a internet. Podem ser pequenos, podem ser focados em temas específicos, indo do básico ao avançado. É a melhor forma de aprender a fazer mais e melhor.
Quem se habilita?
Este é um problema realmente grave?
Acredito que não, mas que é um ponto que pode ser melhor trabalhado pela comunidade do PostgreSQL.
segunda-feira, 23 de junho de 2008
Limitações: Configuração de Case Sensitivity and Accent Sensitivity
A partir de hoje colocarei à medida que forem surgindo, limitações que encontro no PostgreSQL. A primeira limitação a ser mencionada é a falta de uma configuração para Case Sensitivity e Accent Sensitivity no SGBD.
Case Sensitivity e Accent Sensitivity são características particularmente desejáveis nos bancos de dados atuais. A não existência de configuração para o armazenamento e/ou recuperação de dados com base nestas características é uma lacuna a ser preenchida neste banco de dados. Atualmente não há este recurso e as buscas de dados levando em conta ou não maiúsculas e minúsculas exigem alterações nas aplicações (com UPPER, LOWER, LIKE e ILIKE).
Uma consulta com Case Sensitivity (sensível ao caso) retorna valores levando em consideração se os caracteres buscados estão em maiúsculas ou minúsculas. Desta forma, a busca pelo valor 'CLA' retorna resultados diferentes da busca por 'Cla'. O não uso de sensitividade nas buscas de caracteres é chamado de Case Insensitivity.
Uma consulta com Accent Sensitivity (sensível ao acento) retorna valores levando em consideração se os caracteres buscados estão em maiúsculas ou minúsculas. Desta forma, a busca pelo valor 'CLA' retorna resultados diferentes da busca por 'Cla'. O não uso de sensitividade nas buscas de caracteres acentuados é chamado de Accent Insensitivity.
Proposta:
- A implementação de tal característica como configuração poderia ser feita para o banco todo, por tablespace, tabela ou visão, facilitando a implementação e evitando alterações nas aplicações mais complexas que necessitam destas funcionalidades.
- Poderia ser feita via comando SET e na criação de objetos do banco, como na de tabelas, indicando que colunas são SENSITIVE e INSENSITIVE.
- O padrão deve ser INSENSITIVE por questões de desempenho.
Ressalvas:
- Novas propostas para esta funcionalidade são bem vindas e podem ser colocadas no comentário deste post.
quarta-feira, 11 de junho de 2008
Formatação de CPF - Uma função simples
O CPF, número do Cadastro de Pessoa Física, apresenta o formato NNN.NNN.NNN-DD, onde N é número do CPF e D é dígito verificador. Uma vez que o mesmo é bastante utilizado, sua validação e apresentação são opções que podem ser implementadas dentro do banco de dados , com reuso do mesmo código para uso em vários sistemas.
Neste post vamos fazer uma função simplificada para formatação e apresentação de CPF.
A consulta abaixo faz a formatação de um CPF. Apresenta a desvantagem de se ter de repetir várias vezes o valor do CPF a ser apresentado.
SELECT substring('12345678912' FROM 1 FOR 3) || '.' || substring('12345678912' FROM 4 FOR 3) || '.' || substring('12345678912' FROM 7 FOR 3) || '-' || substring('12345678912' FROM 10 FOR 2);
O uso de uma função aumenta a simplicidade e facilita o reuso:
CREATE OR REPLACE FUNCTION CPF_formatar(par_cpf varchar(11)) RETURNS varchar(14) AS $$
-- ROTINA DE FORMATAÇÃO DE CPF
-- Código PL/ PGSQL: Cláudio Leopoldino - http://postgresqlbr.blogspot.com/
-- Retorna o CPF formatado no formato NNN.NNN.NNN-DD, onde N é número do CPF e D é dígito verificador
-- em caso de erro retorna 'ERRO'
BEGIN
IF char_length(par_cpf) != 11 THEN
RAISE NOTICE 'Formato inválido: %',$1;
RETURN 'ERRO';
END IF;
RETURN substring(par_cpf FROM 1 FOR 3) || '.' || substring(par_cpf FROM 4 FOR 3) || '.' || substring(par_cpf FROM 7 FOR 3) || '-' || substring(par_cpf FROM 10 FOR 2);
END;
$$ LANGUAGE PLPGSQL;
SELECT CPF_formatar('12345678912');
Neste post vamos fazer uma função simplificada para formatação e apresentação de CPF.
A consulta abaixo faz a formatação de um CPF. Apresenta a desvantagem de se ter de repetir várias vezes o valor do CPF a ser apresentado.
SELECT substring('12345678912' FROM 1 FOR 3) || '.' || substring('12345678912' FROM 4 FOR 3) || '.' || substring('12345678912' FROM 7 FOR 3) || '-' || substring('12345678912' FROM 10 FOR 2);
O uso de uma função aumenta a simplicidade e facilita o reuso:
CREATE OR REPLACE FUNCTION CPF_formatar(par_cpf varchar(11)) RETURNS varchar(14) AS $$
-- ROTINA DE FORMATAÇÃO DE CPF
-- Código PL/ PGSQL: Cláudio Leopoldino - http://postgresqlbr.blogspot.com/
-- Retorna o CPF formatado no formato NNN.NNN.NNN-DD, onde N é número do CPF e D é dígito verificador
-- em caso de erro retorna 'ERRO'
BEGIN
IF char_length(par_cpf) != 11 THEN
RAISE NOTICE 'Formato inválido: %',$1;
RETURN 'ERRO';
END IF;
RETURN substring(par_cpf FROM 1 FOR 3) || '.' || substring(par_cpf FROM 4 FOR 3) || '.' || substring(par_cpf FROM 7 FOR 3) || '-' || substring(par_cpf FROM 10 FOR 2);
END;
$$ LANGUAGE PLPGSQL;
SELECT CPF_formatar('12345678912');
domingo, 8 de junho de 2008
Validação de CPF com Pl/ PgSQL
A partir de hoje passamos a divulgar algoritmos de funções e consultas que sejam de utilidade pública. A validação de CPF com Pl/ PgSQL foi escolhida em primeiro lugar por ser um algoritmo simples mas bastante útil (além disto, procurei em vários sites e não encontrei um exemplo em PL/ PGSQL).
O CPF é utilizado por muitos sistemas brasileiros como identificação dos indivíduos. Validar o CPF é fazer a verificação dos dois últimos dígitos que são gerados a partir dos nove primeiros. O código abaixo foi uma tradução mais ou menos literal do código em javascript deste site.
Talvez possa ser feita otimização ou melhoria neste algoritmo, mas a idéia é que vocês o melhorem e atualizem neste site. Estejam à vontade para utilizar e compartilhar este código.
CREATE OR REPLACE FUNCTION CPF_Validar(par_cpf varchar(11)) RETURNS integer AS $$
-- ROTINA DE VALIDAÇÃO DE CPF
-- Conversão para o PL/ PGSQL: Cláudio Leopoldino - http://postgresqlbr.blogspot.com/
-- Algoritmo original: http://webmasters.neting.com/msg07743.html
-- Retorna 1 para CPF correto.
DECLARE
x real;
y real; --Variável temporária
soma integer;
dig1 integer; --Primeiro dígito do CPF
dig2 integer; --Segundo dígito do CPF
len integer; -- Tamanho do CPF
contloop integer; --Contador para loop
val_par_cpf varchar(11); --Valor do parâmetro
BEGIN
-- Teste do tamanho da string de entrada
IF char_length(par_cpf) = 11 THEN
ELSE
RAISE NOTICE 'Formato inválido: %',$1;
RETURN 0;
END IF;
-- Inicialização
x := 0;
soma := 0;
dig1 := 0;
dig2 := 0;
contloop := 0;
val_par_cpf := $1; --Atribuição do parâmetro a uma variável interna
len := char_length(val_par_cpf);
x := len -1;
--Loop de multiplicação - dígito 1
contloop :=1;
WHILE contloop <= (len -2) LOOP
y := CAST(substring(val_par_cpf from contloop for 1) AS NUMERIC);
soma := soma + ( y * x);
x := x - 1;
contloop := contloop +1;
END LOOP;
dig1 := 11 - CAST((soma % 11) AS INTEGER);
if (dig1 = 10) THEN dig1 :=0 ; END IF;
if (dig1 = 11) THEN dig1 :=0 ; END IF;
-- Dígito 2
x := 11; soma :=0;
contloop :=1;
WHILE contloop <= (len -1) LOOP
soma := soma + CAST((substring(val_par_cpf FROM contloop FOR 1)) AS REAL) * x;
x := x - 1;
contloop := contloop +1;
END LOOP;
dig2 := 11 - CAST ((soma % 11) AS INTEGER);
IF (dig2 = 10) THEN dig2 := 0; END IF;
IF (dig2 = 11) THEN dig2 := 0; END IF;
--Teste do CPF
IF ((dig1 || '' || dig2) = substring(val_par_cpf FROM len-1 FOR 2)) THEN
RETURN 1;
ELSE
RAISE NOTICE 'DV do CPF Inválido: %',$1;
RETURN 0;
END IF;
END;
$$ LANGUAGE PLPGSQL;
O CPF é utilizado por muitos sistemas brasileiros como identificação dos indivíduos. Validar o CPF é fazer a verificação dos dois últimos dígitos que são gerados a partir dos nove primeiros. O código abaixo foi uma tradução mais ou menos literal do código em javascript deste site.
Talvez possa ser feita otimização ou melhoria neste algoritmo, mas a idéia é que vocês o melhorem e atualizem neste site. Estejam à vontade para utilizar e compartilhar este código.
CREATE OR REPLACE FUNCTION CPF_Validar(par_cpf varchar(11)) RETURNS integer AS $$
-- ROTINA DE VALIDAÇÃO DE CPF
-- Conversão para o PL/ PGSQL: Cláudio Leopoldino - http://postgresqlbr.blogspot.com/
-- Algoritmo original: http://webmasters.neting.com/msg07743.html
-- Retorna 1 para CPF correto.
DECLARE
x real;
y real; --Variável temporária
soma integer;
dig1 integer; --Primeiro dígito do CPF
dig2 integer; --Segundo dígito do CPF
len integer; -- Tamanho do CPF
contloop integer; --Contador para loop
val_par_cpf varchar(11); --Valor do parâmetro
BEGIN
-- Teste do tamanho da string de entrada
IF char_length(par_cpf) = 11 THEN
ELSE
RAISE NOTICE 'Formato inválido: %',$1;
RETURN 0;
END IF;
-- Inicialização
x := 0;
soma := 0;
dig1 := 0;
dig2 := 0;
contloop := 0;
val_par_cpf := $1; --Atribuição do parâmetro a uma variável interna
len := char_length(val_par_cpf);
x := len -1;
--Loop de multiplicação - dígito 1
contloop :=1;
WHILE contloop <= (len -2) LOOP
y := CAST(substring(val_par_cpf from contloop for 1) AS NUMERIC);
soma := soma + ( y * x);
x := x - 1;
contloop := contloop +1;
END LOOP;
dig1 := 11 - CAST((soma % 11) AS INTEGER);
if (dig1 = 10) THEN dig1 :=0 ; END IF;
if (dig1 = 11) THEN dig1 :=0 ; END IF;
-- Dígito 2
x := 11; soma :=0;
contloop :=1;
WHILE contloop <= (len -1) LOOP
soma := soma + CAST((substring(val_par_cpf FROM contloop FOR 1)) AS REAL) * x;
x := x - 1;
contloop := contloop +1;
END LOOP;
dig2 := 11 - CAST ((soma % 11) AS INTEGER);
IF (dig2 = 10) THEN dig2 := 0; END IF;
IF (dig2 = 11) THEN dig2 := 0; END IF;
--Teste do CPF
IF ((dig1 || '' || dig2) = substring(val_par_cpf FROM len-1 FOR 2)) THEN
RETURN 1;
ELSE
RAISE NOTICE 'DV do CPF Inválido: %',$1;
RETURN 0;
END IF;
END;
$$ LANGUAGE PLPGSQL;
segunda-feira, 2 de junho de 2008
PGCon 2008: Seja um palestrante!
Uma das melhores formas de colaborar com a comunidade de software livre é compartilhar os conhecimentos. A PGCon 2008 oficialmente divulgou hoje a chamada de palestras e tutoriais.
A PGCon é a maior convenção brasileira, e possivelmente latino-americana de PostgreSQL. O site da edição de 2008 que ocorrerá dias 26 e 27 de Setembro de 2008 no Centro de Convenções da Unicamp em Campinas, SP, já está no ar aqui!
Esta é uma arena aberta àqueles que têm o espírito de compartilhamento e conteúdo para divulgar. Não perca esta oportunidade!
===================================================
Comunicado Oficial:
===================================================
A Comunidade Brasileira de PostgreSQL tem o prazer de convida-lo para
participar do PGCon Brasil 2008[1]. Após a realização do PGCon Brasil
2007[2], estamos novamente convidando a comunidade brasileira a enviar
suas propostas de trabalho para a segunda edição deste evento. O PGCon
Brasil 2008 será realizado nos dias 26 e 27 de setembro de 2008 na
UNICAMP[3] (Campinas-SP).
* Instruções:
- As palestras terão duração de 50 minutos, incluindo o tempo
para as perguntas. Haverá também a escolha de apenas um tutorial
que poderá ter até 120 minutos de duração.
- Qualquer palestrante pode enviar mais de uma proposta;
- O PGCon Brasil não se responsabiliza pelos gastos
com deslocamento, hospedagem e alimentação dos palestrantes;
- Todas as propostas deverão ser enviadas até 22/06/2008 em
formato texto para o e-mail; "pgcon@postgresql.org.br" contendo o
seguinte formulário:
* Formulário:
o Nome completo
o E-mail
o Telefones de contato
o Endereço completo
o Local de onde você virá (UF / Cidade)
o Mini currículo (até 500 caracteres)
o Título
o Tipo (palestra e/ou tutorial)
o Nível (iniciante, intermediário ou avançado)
o Resumo da palestra (até 500 caracteres)
o Descrição completa da palestra (até 3000 caracteres)
* Calendário:
- 02/06/2008 - Publicação da chamada de trabalhos;
- 22/06/2008 - Última data para envio de propostas;
- 11/07/2008 - Última data para seleção de palestras e envio
dos resultados aos palestrantes;
- 18/07/2008 - Última data para confirmação das palestras
selecionadas e publicação do resultado;
- 15/08/2008 - Última data para envio do rascunho das apresentações;
- 24/09/2008 - Última data para envio da versão final das apresentações;
A PGCon é a maior convenção brasileira, e possivelmente latino-americana de PostgreSQL. O site da edição de 2008 que ocorrerá dias 26 e 27 de Setembro de 2008 no Centro de Convenções da Unicamp em Campinas, SP, já está no ar aqui!
Esta é uma arena aberta àqueles que têm o espírito de compartilhamento e conteúdo para divulgar. Não perca esta oportunidade!
===================================================
Comunicado Oficial:
===================================================
A Comunidade Brasileira de PostgreSQL tem o prazer de convida-lo para
participar do PGCon Brasil 2008[1]. Após a realização do PGCon Brasil
2007[2], estamos novamente convidando a comunidade brasileira a enviar
suas propostas de trabalho para a segunda edição deste evento. O PGCon
Brasil 2008 será realizado nos dias 26 e 27 de setembro de 2008 na
UNICAMP[3] (Campinas-SP).
* Instruções:
- As palestras terão duração de 50 minutos, incluindo o tempo
para as perguntas. Haverá também a escolha de apenas um tutorial
que poderá ter até 120 minutos de duração.
- Qualquer palestrante pode enviar mais de uma proposta;
- O PGCon Brasil não se responsabiliza pelos gastos
com deslocamento, hospedagem e alimentação dos palestrantes;
- Todas as propostas deverão ser enviadas até 22/06/2008 em
formato texto para o e-mail; "pgcon@postgresql.org.br" contendo o
seguinte formulário:
* Formulário:
o Nome completo
o E-mail
o Telefones de contato
o Endereço completo
o Local de onde você virá (UF / Cidade)
o Mini currículo (até 500 caracteres)
o Título
o Tipo (palestra e/ou tutorial)
o Nível (iniciante, intermediário ou avançado)
o Resumo da palestra (até 500 caracteres)
o Descrição completa da palestra (até 3000 caracteres)
* Calendário:
- 02/06/2008 - Publicação da chamada de trabalhos;
- 22/06/2008 - Última data para envio de propostas;
- 11/07/2008 - Última data para seleção de palestras e envio
dos resultados aos palestrantes;
- 18/07/2008 - Última data para confirmação das palestras
selecionadas e publicação do resultado;
- 15/08/2008 - Última data para envio do rascunho das apresentações;
- 24/09/2008 - Última data para envio da versão final das apresentações;
quinta-feira, 29 de maio de 2008
Uso de SET em Funções Pl/PgSQL
Na versão 8.3 do PostgreSQL foi implementado um recurso interessante, que permite a parametrização da execução de uma função utilizando o comando SET no momento da sua criação. Desta forma, a configuração é alterada apenas durante a sua execução, retornando aos valores prévios após o seu encerramento.
Valores de tablespace padrão (default_tablespace), encoding do cliente (client_encoding) entre outros são definidos de forma explícita, de modo que se force o comportamento esperado da função não importando que programa faça a sua chamada de execução.
Existe também a opção de utilização da cláusula FROM CURRENT para fazer com que a alteração de configuração seja mantida após a execução da função.
Nem todos os parâmetros de execução podem ser alterados com o comando SET dentro de uma função. Os erros são revelados no momento de criação da função.
O comando SHOW mostra a lista de parâmetros e seus valores correntes.
Criação de Função com Parâmetros de Configuração
O código abaixo mostra a criação de uma função que atualiza a tabela salário. Após o corpo da função são definidos os valores dos itens de configuração array_nulls, default_tablespace, commit_delay e client_encoding.
CREATE TABLE SALARIO (cod integer PRIMARY KEY, provento real);
INSERT INTO SALARIO VALUES (1, 1000.00);
INSERT INTO SALARIO VALUES (2, 100.00);
CREATE OR REPLACE FUNCTION salario_aumento() RETURNS BOOLEAN AS $
BEGIN
UPDATE SALARIO SET provento = provento * 1.1;
RETURN true;
END;
$ LANGUAGE plpgsql
SET array_nulls = OFF
SET default_tablespace = 'pg_default'
SET commit_delay TO 10
SET client_encoding TO UNICODE;
Mantendo Alterações na Configuração
O código abaixo mostra a criação de uma função na qual é alterado e mantido o valor do client_encoding. A cláusula FROM CURRENT indica que parâmetro terá o valor de configuração que foi alterado mantido.
CREATE OR REPLACE FUNCTION salario_parametros() RETURNS BOOLEAN AS $
BEGIN
UPDATE SALARIO SET provento = provento * 1.1;
RETURN true;
END;
$ LANGUAGE plpgsql
SET client_encoding TO UNICODE
SET client_encoding FROM CURRENT;
Ressalva no Uso de SET em Funções
Alguns dos itens de configuração não são alteráveis pelo comando SET dentro de uma função. Neste caso, será retornado erro no ato da criação da função. No exemplo abaixo, tanto o log_checkpoints quanto o transaction_isolation não puderam ser alterados no escopo de uma função.
-- Não funcionaram
CREATE OR REPLACE FUNCTION salario_parametros_teste() RETURNS BOOLEAN AS $
BEGIN
UPDATE SALARIO SET provento = provento * 1.1;
RETURN true;
END;
$ LANGUAGE plpgsql
SET log_checkpoints = ON
SET transaction_isolation = SERIALIZABLE;
ERROR: parameter "log_checkpoints" cannot be changed now
********** Error **********
ERROR: parameter "log_checkpoints" cannot be changed now
SQL state: 55P02
Valores de tablespace padrão (default_tablespace), encoding do cliente (client_encoding) entre outros são definidos de forma explícita, de modo que se force o comportamento esperado da função não importando que programa faça a sua chamada de execução.
Existe também a opção de utilização da cláusula FROM CURRENT para fazer com que a alteração de configuração seja mantida após a execução da função.
Nem todos os parâmetros de execução podem ser alterados com o comando SET dentro de uma função. Os erros são revelados no momento de criação da função.
O comando SHOW mostra a lista de parâmetros e seus valores correntes.
Criação de Função com Parâmetros de Configuração
O código abaixo mostra a criação de uma função que atualiza a tabela salário. Após o corpo da função são definidos os valores dos itens de configuração array_nulls, default_tablespace, commit_delay e client_encoding.
CREATE TABLE SALARIO (cod integer PRIMARY KEY, provento real);
INSERT INTO SALARIO VALUES (1, 1000.00);
INSERT INTO SALARIO VALUES (2, 100.00);
CREATE OR REPLACE FUNCTION salario_aumento() RETURNS BOOLEAN AS $
BEGIN
UPDATE SALARIO SET provento = provento * 1.1;
RETURN true;
END;
$ LANGUAGE plpgsql
SET array_nulls = OFF
SET default_tablespace = 'pg_default'
SET commit_delay TO 10
SET client_encoding TO UNICODE;
Mantendo Alterações na Configuração
O código abaixo mostra a criação de uma função na qual é alterado e mantido o valor do client_encoding. A cláusula FROM CURRENT indica que parâmetro terá o valor de configuração que foi alterado mantido.
CREATE OR REPLACE FUNCTION salario_parametros() RETURNS BOOLEAN AS $
BEGIN
UPDATE SALARIO SET provento = provento * 1.1;
RETURN true;
END;
$ LANGUAGE plpgsql
SET client_encoding TO UNICODE
SET client_encoding FROM CURRENT;
Ressalva no Uso de SET em Funções
Alguns dos itens de configuração não são alteráveis pelo comando SET dentro de uma função. Neste caso, será retornado erro no ato da criação da função. No exemplo abaixo, tanto o log_checkpoints quanto o transaction_isolation não puderam ser alterados no escopo de uma função.
-- Não funcionaram
CREATE OR REPLACE FUNCTION salario_parametros_teste() RETURNS BOOLEAN AS $
BEGIN
UPDATE SALARIO SET provento = provento * 1.1;
RETURN true;
END;
$ LANGUAGE plpgsql
SET log_checkpoints = ON
SET transaction_isolation = SERIALIZABLE;
ERROR: parameter "log_checkpoints" cannot be changed now
********** Error **********
ERROR: parameter "log_checkpoints" cannot be changed now
SQL state: 55P02
quarta-feira, 14 de maio de 2008
Acessando o PostgreSQL a partir do OpenOffice Base com SDBC
O BrOffice Base é um banco de dados com características similares às do Microsoft Access. Dentre seus recursos, a interface com o usuário e os vários assistentes e funcionalidades de interface para a criação de tabelas, consultas, formulários e relatórios diversos tornaram esta ferramenta uma boa e produtiva opção para implementadores.
No entanto, bancos como o PostgreSQL apresentam maior robustez e recursos de gerenciamento. Você pode utilizar no seu projeto a produtividade do Base com a robustez do PostgreSQL. A integração é simples e neste texto é mostrada a integração via SDBC - Star(Office) DataBase Connectivity. Outras opções de midlleware de conexão seriam JDBC, ODBC e unixodbc. Cada uma destas tecnologias têm suas vantagens e limitações que estão fora do escopo deste texto.
O SDBC é um padrão que tem sido atualizado constantemente, daí a ser um dos mais empregados, ao lado do JDBC, tendo a vantagem de ser desatrelado à tecnologia Java.
1 - Instalação do Driver SDBC
Fazer o Download do Driver SDBC no site http://dba.openoffice.org/drivers/postgresql/index.html. No meu caso, criei uma pasta e fiz o download do arquivo compactado para:
C:\Program Files\PostgreSQL\8.3\SDBC.
A instalação do SDBC Driver pode ser feita pelo Writer ou outro programa do BrOffice. Todos os demais programas (de apresentações, planilha, etc.) poderão utilizá-lo. Selecione no menu menu Ferramentas\ Gerenciador de extensão... (Tools\Extension Manager)
Clique no botão adicionar e indique o caminho do arquivo compactado com o driver. Selecione o arquivo que você baixou e o BrOffice vai adicionar o driver.
2 - Configuração do Base para a Conexão.
Após instalar o driver, deve ser reiniciado o BrOffice para que o mesmo apareça para o BrOffice Base. A partir daí será possível a conexão.
Abra o Base e selecione a opção de conexão a um banco de dados existente. Desta forma, você ingressará em um assistente de conexão bem simplificado. Após a instalação do driver SDBC aparecerá em uma grande lista de opções o driver do PostgreSQL.
Após selecionar o PostgreSQL e disparar próximo, aparecerá um campo para digitação de parâmetros. Entre com o host e o nome do banco. Abaixo, os valores testados no exemplo.
host=localhost dbname=teste
Na próxima tela, é definido o usuário do PostgreSQL que vai conectar-se via Base. Este usuário deve estar previamente cadastrado e com as permissões necessárias. Ainda existe a opção de testar a conexão.
Não desmarque a opção de senha obrigatória a não ser que haja uma boa razão. De outro modo, a segurança do seu SGBD estará em risco.
Na última tela do assistente, se escolhe se o banco de dados passa a ser registrado na ferramenta. Em caso afirmativo, o Base vai gravar um arquivo de configurações para reutilização. Você pode gravá-lo na pasta do driver SDBC ou em outro lugar para melhor gerenciamento.
3 - Utilização
Após a conexão via assistente, o Base vai abrir a tela e mostrar os esquemas e objetos do PostgreSQL com a sua própria interface visual. É uma maneira de trabalhar com banco de dados de forma produtiva, pois é possível criar formulários e relatórios de forma rápida e simples, acessível a leigos, por exemplo. Para maiores detalhes, procurar por bons sites de BrOffice Base.
4 - Ressalvas
Os outros middlewares para conexão devem ser explorados por possuírem vantagens/ desvantagens diferentes do SDBC. Praticamente todos apresentam bugs conhecidos e limitações.
A questão de como utilizar o potencial do BrOffice Base está em aberto. A criatividade e adesão dos usuários é que vai fazer ou não este casamento frutificar.
No entanto, bancos como o PostgreSQL apresentam maior robustez e recursos de gerenciamento. Você pode utilizar no seu projeto a produtividade do Base com a robustez do PostgreSQL. A integração é simples e neste texto é mostrada a integração via SDBC - Star(Office) DataBase Connectivity. Outras opções de midlleware de conexão seriam JDBC, ODBC e unixodbc. Cada uma destas tecnologias têm suas vantagens e limitações que estão fora do escopo deste texto.
O SDBC é um padrão que tem sido atualizado constantemente, daí a ser um dos mais empregados, ao lado do JDBC, tendo a vantagem de ser desatrelado à tecnologia Java.
1 - Instalação do Driver SDBC
Fazer o Download do Driver SDBC no site http://dba.openoffice.org/drivers/postgresql/index.html. No meu caso, criei uma pasta e fiz o download do arquivo compactado para:
C:\Program Files\PostgreSQL\8.3\SDBC.
A instalação do SDBC Driver pode ser feita pelo Writer ou outro programa do BrOffice. Todos os demais programas (de apresentações, planilha, etc.) poderão utilizá-lo. Selecione no menu menu Ferramentas\ Gerenciador de extensão... (Tools\Extension Manager)
Clique no botão adicionar e indique o caminho do arquivo compactado com o driver. Selecione o arquivo que você baixou e o BrOffice vai adicionar o driver.
2 - Configuração do Base para a Conexão.
Após instalar o driver, deve ser reiniciado o BrOffice para que o mesmo apareça para o BrOffice Base. A partir daí será possível a conexão.
Abra o Base e selecione a opção de conexão a um banco de dados existente. Desta forma, você ingressará em um assistente de conexão bem simplificado. Após a instalação do driver SDBC aparecerá em uma grande lista de opções o driver do PostgreSQL.
Após selecionar o PostgreSQL e disparar próximo, aparecerá um campo para digitação de parâmetros. Entre com o host e o nome do banco. Abaixo, os valores testados no exemplo.
host=localhost dbname=teste
Na próxima tela, é definido o usuário do PostgreSQL que vai conectar-se via Base. Este usuário deve estar previamente cadastrado e com as permissões necessárias. Ainda existe a opção de testar a conexão.
Não desmarque a opção de senha obrigatória a não ser que haja uma boa razão. De outro modo, a segurança do seu SGBD estará em risco.
Na última tela do assistente, se escolhe se o banco de dados passa a ser registrado na ferramenta. Em caso afirmativo, o Base vai gravar um arquivo de configurações para reutilização. Você pode gravá-lo na pasta do driver SDBC ou em outro lugar para melhor gerenciamento.
3 - Utilização
Após a conexão via assistente, o Base vai abrir a tela e mostrar os esquemas e objetos do PostgreSQL com a sua própria interface visual. É uma maneira de trabalhar com banco de dados de forma produtiva, pois é possível criar formulários e relatórios de forma rápida e simples, acessível a leigos, por exemplo. Para maiores detalhes, procurar por bons sites de BrOffice Base.
4 - RessalvasOs outros middlewares para conexão devem ser explorados por possuírem vantagens/ desvantagens diferentes do SDBC. Praticamente todos apresentam bugs conhecidos e limitações.
A questão de como utilizar o potencial do BrOffice Base está em aberto. A criatividade e adesão dos usuários é que vai fazer ou não este casamento frutificar.
segunda-feira, 28 de abril de 2008
Você Realmente Conhece a Versão 8.3 e suas Novidades?
Semana passada apresentei uma palestra com este tema e fiz um mapa mental com a ferramenta livre Freemind para organizar o conteúdo e dar uma estética melhor.
Coloquei as principais alterações da versão 8.3 e gerei uma imagem. Quem precisar, pode utilizá-la. Sugestões de melhoria também são bem vindas. Com certeza esqueci algum detalhe. As informações são da própria documentação do PostgreSQL.
Coloquei as principais alterações da versão 8.3 e gerei uma imagem. Quem precisar, pode utilizá-la. Sugestões de melhoria também são bem vindas. Com certeza esqueci algum detalhe. As informações são da própria documentação do PostgreSQL.
sexta-feira, 18 de abril de 2008
101 Posts!
Este é o Post número 101 deste blog. Mais que um número, é uma conquista que credito a cada um dos freqüentadores. O que era o "Meu Blog" está cada dia mais se tornando um recurso da
comunidade, que colabora com idéias, textos, críticas, sugestões e com a divulgação deste link.
Dia 04/04/07, depois de uma resolução tomada no meu aniversário, resolvi começar este blog para me forçar a estar sempre estudando Banco de Dados, uma vez que ministrava uma disciplina na área e não era um verdadeiro DBA nos meus empregos (e também para conhecer o funcionamento interno de um blog!). Aos poucos o conteúdo foi se distanciando da disciplina, que não estou mais ensinando, e se tornou uma pequena base de dados sobre o PostgreSQL. Os acessos foram aumentando e sem querer fui conhecendo mais da comunidade do Banco de Dados do elefantinho.
O reconhecimento da comunidade tem sido recompensador, e fez com que este site sempre apareça entre os primeiros blogs de PostgreSQL a serem recuperados no Google, considerando não só o Brasil, mas todo o planeta. O número de links e referências a este site também cresceram bastante e atingiram algumas centenas, o que é raro em blogs tão específicos. É motivo para maior cuidado e para a busca de novas idéias para um constante aprimoramento. Convites para consultorias e treinamentos, que quase nunca posso atender, atestam que este veículo alcança um grande contingente de pessoas. Que bom!
(Pessoalmente, sou um grande usuário, pois consulto as notas que eu mesmo postei no blog quando estou em dúvida.)
Claro que existem dificuldades: cada vez menos tempo, mais responsabilidades no mundo fora da internet e uma maior dificuldade em ter novas idéias. Neste período, vários outros blogs surgiram e desapareceram. Muitos deles pararam no tempo, sem atualização, ou patinam sem conseguir conciliar qualidade e um bom ritmo. Mas o grande estímulo para oferecer algo, para difundir conhecimento tem ajudado nos momentos mais difíceis.
Se você está lendo este post, saiba que este é um espaço para:
- Divulgar seu site/ evento/ notícia de PostgreSQL
- Propor soluções de problemas
- Apresentar problemas e questionamentos
- Pesquisar
- Votar em enquetes (estou pensando em criar mais...)
Tentarei manter este espaço sempre atualizado e em sintonia com a evolução da tecnologia. Quero melhorar seus materiais e conto com a sua colaboração!
Espero poder continuar colaborando para que outras pessoas também se beneficiem por muito tempo ainda.
Agradeço a todos que lêem este post e a todos os freqüentadores do "Meu Blog de PostgreSQL".
comunidade, que colabora com idéias, textos, críticas, sugestões e com a divulgação deste link.
Dia 04/04/07, depois de uma resolução tomada no meu aniversário, resolvi começar este blog para me forçar a estar sempre estudando Banco de Dados, uma vez que ministrava uma disciplina na área e não era um verdadeiro DBA nos meus empregos (e também para conhecer o funcionamento interno de um blog!). Aos poucos o conteúdo foi se distanciando da disciplina, que não estou mais ensinando, e se tornou uma pequena base de dados sobre o PostgreSQL. Os acessos foram aumentando e sem querer fui conhecendo mais da comunidade do Banco de Dados do elefantinho.
O reconhecimento da comunidade tem sido recompensador, e fez com que este site sempre apareça entre os primeiros blogs de PostgreSQL a serem recuperados no Google, considerando não só o Brasil, mas todo o planeta. O número de links e referências a este site também cresceram bastante e atingiram algumas centenas, o que é raro em blogs tão específicos. É motivo para maior cuidado e para a busca de novas idéias para um constante aprimoramento. Convites para consultorias e treinamentos, que quase nunca posso atender, atestam que este veículo alcança um grande contingente de pessoas. Que bom!
(Pessoalmente, sou um grande usuário, pois consulto as notas que eu mesmo postei no blog quando estou em dúvida.)
Claro que existem dificuldades: cada vez menos tempo, mais responsabilidades no mundo fora da internet e uma maior dificuldade em ter novas idéias. Neste período, vários outros blogs surgiram e desapareceram. Muitos deles pararam no tempo, sem atualização, ou patinam sem conseguir conciliar qualidade e um bom ritmo. Mas o grande estímulo para oferecer algo, para difundir conhecimento tem ajudado nos momentos mais difíceis.
Se você está lendo este post, saiba que este é um espaço para:
- Divulgar seu site/ evento/ notícia de PostgreSQL
- Propor soluções de problemas
- Apresentar problemas e questionamentos
- Pesquisar
- Votar em enquetes (estou pensando em criar mais...)
Tentarei manter este espaço sempre atualizado e em sintonia com a evolução da tecnologia. Quero melhorar seus materiais e conto com a sua colaboração!
Espero poder continuar colaborando para que outras pessoas também se beneficiem por muito tempo ainda.
Agradeço a todos que lêem este post e a todos os freqüentadores do "Meu Blog de PostgreSQL".
sexta-feira, 11 de abril de 2008
Uso de UUIDs no PostgreSQL
Implementado no PostgreSQL 8.3, o tipo de dado UUID (Universally Unique Identifier) é pouco conhecido e pouco utilizado. Em post anterior, descrevi esta funcionalidade. Agora demonstrarei como a mesma foi implementada e como pode ser empregada para inserção e alteração de dados, consulta, dentro de funções e com tipos compostos.
Inicialmente, vamos criar uma tabela com campo do tipo UUID e fazer operações de inserção e consulta aos dados. A sintaxe se mantém a mesma para a inserção e alteração de dados. Campos UUID são similares a campos caractere, com a diferença de terem os caracteres "-" opcionais.
Um fato interessante é que o PostgreSQL não apresenta algoritmo padrão para a geração de UUIDs, uma vez que não foi obtido consenso sobre a melhor opção. Cabe ao desenvolvedor criar seu algoritmo e colocá-lo na aplicação ou no banco como função, ou obter um gerador de outras fontes.
--Criação de tabela com campo UUID e inserção de registros
CREATE TABLE uuid_test (identidade UUID);
INSERT INTO uuid_test VALUES ('a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11');
INSERT INTO uuid_test VALUES ('12345678-9c0b-4ef8-bb6d-6bb9bd380a11');
INSERT INTO uuid_test VALUES ('82345678-9c0b-4ef8-bb6d-6bb9bd380a11');
INSERT INTO uuid_test VALUES ('723456789c0b4ef8bb6d6bb9bd380a11'); --Pode ser feita inserção sem os "-"
SELECT * FROM uuid_test;
--Consultas de UUID, incluindo consulta com conversão para UUID
SELECT '12345678-9c0b-4ef8-bb6d-6bb9bd380a11' = UUID('123456789c0b4ef8bb6d6bb9bd380a11');
SELECT UUID('12345678-9c0b-4ef8-bb6d-6bb9bd380a11'), UUID('123456789c0b4ef8bb6d6bb9bd380a11');
SELECT UUID('12345678-9c0b-4ef8-bb6d-6bb9bd380a11') = UUID('123456789c0b4ef8bb6d6bb9bd380a11');
Funções podem retornar dados do tipo UUID, inclusive em conjuntos de linhas (SETOF). Abaixo apresento duas funções, uma retornando um UUID simples e outra retornando um conjunto de linhas com UUIDs.
--Função SIMPLES que retorna tipo UUID
CREATE FUNCTION ret_uuid_simples () RETURNS uuid AS $$
BEGIN
RETURN '12345678-9c0b-4ef8-bb6d-6bb9bd380a11';
END;
$$ LANGUAGE plpgsql;
SELECT * FROM ret_uuid_simples();
--Função que retorna tipo UUID
CREATE FUNCTION ret_uuid () RETURNS SETOF uuid AS $$
BEGIN
RETURN QUERY SELECT identidade FROM uuid_test LIMIT 1;
RETURN;
END;
$$ LANGUAGE plpgsql;
SELECT * FROM ret_uuid();
O tipo de dado UUID pode ser utilizado na construção de tipos que podem ser reaproveitados.
--Uso de UUID em tipos
CREATE TYPE pessoa_uuid AS (nome varchar(50), ident UUID);
CREATE table ALUNO_UUID (
nomealu pessoa_uuid NOT NULL,
nasc date,
serie int);
INSERT INTO ALUNO_UUID VALUES (('Carla Paulina','82345678-9c0b-4ef8-bb6d-6bb9bd380a11'), '12/12/2001',1);
SELECT * FROM ALUNO_UUID;
SELECT nomealu, (nomealu).nome, (nomealu).ident FROM ALUNO_UUID;
Inicialmente, vamos criar uma tabela com campo do tipo UUID e fazer operações de inserção e consulta aos dados. A sintaxe se mantém a mesma para a inserção e alteração de dados. Campos UUID são similares a campos caractere, com a diferença de terem os caracteres "-" opcionais.
Um fato interessante é que o PostgreSQL não apresenta algoritmo padrão para a geração de UUIDs, uma vez que não foi obtido consenso sobre a melhor opção. Cabe ao desenvolvedor criar seu algoritmo e colocá-lo na aplicação ou no banco como função, ou obter um gerador de outras fontes.
--Criação de tabela com campo UUID e inserção de registros
CREATE TABLE uuid_test (identidade UUID);
INSERT INTO uuid_test VALUES ('a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11');
INSERT INTO uuid_test VALUES ('12345678-9c0b-4ef8-bb6d-6bb9bd380a11');
INSERT INTO uuid_test VALUES ('82345678-9c0b-4ef8-bb6d-6bb9bd380a11');
INSERT INTO uuid_test VALUES ('723456789c0b4ef8bb6d6bb9bd380a11'); --Pode ser feita inserção sem os "-"
SELECT * FROM uuid_test;
--Consultas de UUID, incluindo consulta com conversão para UUID
SELECT '12345678-9c0b-4ef8-bb6d-6bb9bd380a11' = UUID('123456789c0b4ef8bb6d6bb9bd380a11');
SELECT UUID('12345678-9c0b-4ef8-bb6d-6bb9bd380a11'), UUID('123456789c0b4ef8bb6d6bb9bd380a11');
SELECT UUID('12345678-9c0b-4ef8-bb6d-6bb9bd380a11') = UUID('123456789c0b4ef8bb6d6bb9bd380a11');
Funções podem retornar dados do tipo UUID, inclusive em conjuntos de linhas (SETOF). Abaixo apresento duas funções, uma retornando um UUID simples e outra retornando um conjunto de linhas com UUIDs.
--Função SIMPLES que retorna tipo UUID
CREATE FUNCTION ret_uuid_simples () RETURNS uuid AS $$
BEGIN
RETURN '12345678-9c0b-4ef8-bb6d-6bb9bd380a11';
END;
$$ LANGUAGE plpgsql;
SELECT * FROM ret_uuid_simples();
--Função que retorna tipo UUID
CREATE FUNCTION ret_uuid () RETURNS SETOF uuid AS $$
BEGIN
RETURN QUERY SELECT identidade FROM uuid_test LIMIT 1;
RETURN;
END;
$$ LANGUAGE plpgsql;
SELECT * FROM ret_uuid();
O tipo de dado UUID pode ser utilizado na construção de tipos que podem ser reaproveitados.
--Uso de UUID em tipos
CREATE TYPE pessoa_uuid AS (nome varchar(50), ident UUID);
CREATE table ALUNO_UUID (
nomealu pessoa_uuid NOT NULL,
nasc date,
serie int);
INSERT INTO ALUNO_UUID VALUES (('Carla Paulina','82345678-9c0b-4ef8-bb6d-6bb9bd380a11'), '12/12/2001',1);
SELECT * FROM ALUNO_UUID;
SELECT nomealu, (nomealu).nome, (nomealu).ident FROM ALUNO_UUID;
quinta-feira, 10 de abril de 2008
RETURN QUERY - Novo recurso do PostgreSQL 8.3
A cláusula RETURN QUERY permite que o programador faça uma função que retorne um conjunto de linhas. Foi acrescentada no PostgreSQL 8.3, permitindo maior versatilidade nas implementações.
Para ilustrar esta funcionalidade, vamos criar e popular uma tabela:
CREATE TABLE FUNCTESTE (
cod serial primary key, nome varchar(50), aniversario date default now());
INSERT INTO FUNCTESTE VALUES (1, 'Cláudio', DEFAULT);
...
INSERT INTO FUNCTESTE VALUES (10, 'Ana Cláudia', '01/01/2008');
Vamos retornar um conjunto de linhas utilizando a cláusula RETURN QUERY dentro de uma função. Observe que o código da função abaixo retorna um conjunto de linhas (SETOF) que tem de ser iguais aos campos da tabela FUNCTESTE:
--Retornando consulta de várias linhas com FOR
CREATE OR REPLACE FUNCTION ret_rows () RETURNS SETOF FUNCTESTE AS $$
BEGIN
RETURN QUERY SELECT * FROM FUNCTESTE; -- Acrescenta um conjunto de linhas ao retorno da função
RETURN ; -- Retorna as linhas
END;
$$ LANGUAGE plpgsql;
Para testar a função:
select * from ret_rows();
Em uma função, o RETURN QUERY pode ser utilizado mais de uma vez, mas o retorno feito com RETURN; ´faz a descarga dos valores de uma vez só.
--Retornando a mesma consulta várias vezes com WHILE
CREATE OR REPLACE FUNCTION ret_rows_while () RETURNS SETOF FUNCTESTE AS $$
DECLARE
i INTEGER :=1;
BEGIN
WHILE i <= 5 LOOP
RETURN query SELECT * FROM FUNCTESTE LIMIT 1; --Consulta a ser repetida
i:= i + 1;
END LOOP;
RETURN ;
END;
$$ LANGUAGE plpgsql;
Pode ser retornado um conjunto de elementos de qualquer valor.
--Retornando consulta de vários resultados do tipo inteiro
CREATE OR REPLACE FUNCTION ret_rows_int () RETURNS SETOF integer AS $$
BEGIN
RETURN QUERY SELECT cod FROM FUNCTESTE; --Consulta
RETURN ; -- Retorno de dados
END;
$$ LANGUAGE plpgsql;
select * from ret_rows_int();
A cláusula complementa a função do RETURN NEXT, que era a única possibilidade implementada nas versões anteriores. A sintaxe em geral é mais simples.
Para ilustrar esta funcionalidade, vamos criar e popular uma tabela:
CREATE TABLE FUNCTESTE (
cod serial primary key, nome varchar(50), aniversario date default now());
INSERT INTO FUNCTESTE VALUES (1, 'Cláudio', DEFAULT);
...
INSERT INTO FUNCTESTE VALUES (10, 'Ana Cláudia', '01/01/2008');
Vamos retornar um conjunto de linhas utilizando a cláusula RETURN QUERY dentro de uma função. Observe que o código da função abaixo retorna um conjunto de linhas (SETOF) que tem de ser iguais aos campos da tabela FUNCTESTE:
--Retornando consulta de várias linhas com FOR
CREATE OR REPLACE FUNCTION ret_rows () RETURNS SETOF FUNCTESTE AS $$
BEGIN
RETURN QUERY SELECT * FROM FUNCTESTE; -- Acrescenta um conjunto de linhas ao retorno da função
RETURN ; -- Retorna as linhas
END;
$$ LANGUAGE plpgsql;
Para testar a função:
select * from ret_rows();
Em uma função, o RETURN QUERY pode ser utilizado mais de uma vez, mas o retorno feito com RETURN; ´faz a descarga dos valores de uma vez só.
--Retornando a mesma consulta várias vezes com WHILE
CREATE OR REPLACE FUNCTION ret_rows_while () RETURNS SETOF FUNCTESTE AS $$
DECLARE
i INTEGER :=1;
BEGIN
WHILE i <= 5 LOOP
RETURN query SELECT * FROM FUNCTESTE LIMIT 1; --Consulta a ser repetida
i:= i + 1;
END LOOP;
RETURN ;
END;
$$ LANGUAGE plpgsql;
Pode ser retornado um conjunto de elementos de qualquer valor.
--Retornando consulta de vários resultados do tipo inteiro
CREATE OR REPLACE FUNCTION ret_rows_int () RETURNS SETOF integer AS $$
BEGIN
RETURN QUERY SELECT cod FROM FUNCTESTE; --Consulta
RETURN ; -- Retorno de dados
END;
$$ LANGUAGE plpgsql;
select * from ret_rows_int();
A cláusula complementa a função do RETURN NEXT, que era a única possibilidade implementada nas versões anteriores. A sintaxe em geral é mais simples.
Assinar:
Postagens (Atom)