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');

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;

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;

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


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.

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.


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".

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;

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.

quinta-feira, 27 de março de 2008

PgCon 2008: Ajude a Construir a Grade!

Depois do sucesso da PgCon 2007, a maior convenção de PostgreSQL brasileira, foi iniciada a preparação para a versão 2008 do evento que se realizará em Campinas-SP nos dias 26 e 27 de setembro.

Sugira temas, opine e se envolva nesta ação comunitária. O questionário está disponível no link abaixo:

http://www.midstorm.org/~telles/postgresql/survey.php?sid=29

segunda-feira, 24 de março de 2008

Crie Bases de Dados com o Pagila!

Quem já teve de fazer algum livro, artigo ou material de treinamento em banco sabe o quando é demorado e árduo o processo de criação de uma base de dados fictícia. Cada tabela, relacionamento e dado inserido tem de ser bem pensados ou perdem poder explicativo. A criação de bases com alguns milhares de registros é tediosa e o resultado pode ser cheio de erros e incoerentes com valores inseridos em sistemas reais.

O Pagila é um script que permite a criação de um banco de dados completo para tabelas, chaves primárias e secundárias e demais objetos relacionados, além dos dados. Tem sido utilizado como base de dados para artigos sobre o PostgreSQL, cursos e documentações. Portanto, não se surpreenda se achar as tabelas um pouco familiares. Tabelas de filmes, categorias, clientes e outras são encontradas com os seus respectivos dados, prontas para serem utilizadas na construção de exemplos e testes.

Não é preciso muito conhecimento para compreender o esquema e seus relacionamentos. Os dados são ao mesmo tempo auto-explicativos, similares a situações do mundo real. A única ressalva é que o esquema e os dados estão em inglês, o que pode ser negativo para algumas pessoas.

Originalmente era um script do MySQL desenvolvido por Mike Hillyer do MySQL AB documentation team, que foi portado, sofrendo melhorias para se adequar às funcionalidades do PostgreSQL.

O esquema e seus dados estão disponíveis sob a BSD license (http://www.opensource.org/licenses/bsd-license.php).

Versão atual: 0.10.1
Download: http://pgfoundry.org/frs/?group_id=1000150