Eu gostaria de ressaltar aqui algumas funcionalidades que vão turbinar o desenvolvimento de novas aplicações e/ou facilitar a vida dos DBAs:
1) junções laterais: é uma funcionalidade do padrão SQL que permite que uma subconsulta prefixada com LATERAL possa referenciar colunas de tabelas que estão a esquerda da subconsulta. No exemplo abaixo, m.departamento só pode ser utilizado graças ao LATERAL.
euler=# SELECT nome,salario, media_salario FROM instrutor AS m, LATERAL(SELECT avg(salario) AS media_salario FROM instrutor n WHERE m.departamento = n.departamento) x;
nome | salario | media_salario
--------+---------+---------------
euler | 5023.58 | 3842.04
joao | 1058.21 | 1308.21
maria | 1558.21 | 1308.21
jose | 3758.82 | 3842.04
marcos | 2743.72 | 3842.04
(5 registros)
2) adaptadores de dados externos graváveis: a funcionalidade conhecida como FDW (abreviação de Foreign Data Wrappers) está presente no Postgres desde a versão 9.1. No entanto, tabelas externas não podiam receber modificações (eram somente leitura). Nesta versão foi implementado a escrita e também um novo módulo (postgres_fdw) que vem para substituir o bom e velho dblink. Vale ressaltar que o postgres_fdw em relação ao dblink, possui mais funcionalidades, é mais robusto e transparente além de possuir sintaxe compatível com padrão SQL. Esta funcionalidade vem para facilitar de uma vez por todas o trabalho com bases de dados federadas, ou seja, o desenvolvedor não precisa se preocupar com API de acesso aos seus n SGBDS, basta que ele se conecte ao Postgres que o mesmo fará o acesso aos dados externos para você.
3) memória compartilhada: é comum que novatos no Postgres se deparem com aquele erro clássico "could not create shared memory segment" (principalmente no Linux cuja quantidade de memória compartilhada padrão por usuário é muito baixa -- cerca de 32MB) que aparece quando se tenta aumentar o número de conexões ou o parâmetro shared_buffers. Com uma nova implementação, raramente você precisará fazer o ajuste dos parâmetros do kernel (SHMMAX, SHMALL).
4) gatilhos de eventos: era comum a queixa sobre gatilhos em comandos DDL (CREATE, ALTER, DROP). Principalmente por aqueles interessados em replicação por comandos. A partir de agora, eventos poderão ser diparados ao executar DDLs. Veja um exemplo abaixo:
euler=# CREATE OR REPLACE FUNCTION mensagem() RETURNS event_trigger AS $$
euler$# BEGIN
euler$# RAISE NOTICE 'msg: % %', tg_event, tg_tag;
euler$# END;
euler$# $$ LANGUAGE plpgsql;
CREATE FUNCTION
euler=# CREATE EVENT TRIGGER mensagem ON ddl_command_start EXECUTE PROCEDURE mensagem();
CREATE EVENT TRIGGER
euler=# create table foo (a int);
NOTA: msg: ddl_command_start CREATE TABLE
CREATE TABLE
euler=# drop table foo;
NOTA: msg: ddl_command_start DROP TABLE
DROP TABLE
5) bloqueios: um novo parâmetro (lock_timeout) permite especificar quanto tempo uma sessão esperará por um bloqueio (lock) antes de cancelar o comando. Uma outra funcionalidade importante para concorrência, é permitir que verificações de chave estrangeira não sejam bloqueadas por comandos UPDATE que não atualizam a chave primária da tabela referenciada (não é necessário configurar nada para que isso ocorra).
6) monitoramento: o arquivo contendo as estatísticas do Postgres foi dividido para reduzir a quantidade de I/O em agrupamentos de banco de dados que possuem milhares de objetos. Foi adicionado uma nova opção (só pode ser definida ao criar o agrupamento e não pode ser desabilitada) para fazer a verificação de páginas de dados (também conhecido como checksum); a ideia é detectar rapidamente falha de discos ou hardware com problemas (memória, controladora, etc).
7) replicação: uma das funcionalidades mais esperadas nesta área é a habilidade em detectar mudança de linha do tempo e seguí-la. Explico, se você possui 3 servidores (A, B e C) com o cenário no qual A envia dados para B e B envia dados para C (A -> B -> C). Se ocorrer uma falha em A e você tiver que promover B a servidor principal, você não precisará refazer o servidor C. Isso diminui a complexidade em ambientes de alta disponibilidade.
8) visões: visões materializadas. Isso mesmo! A tão esperada funcionalidade foi implementada com algumas limitações (não suporta atualizações automáticas e as atualizações descartam todos os dados ao invés de atualizações incrementais). Apesar das limitações, a funcionalidade é bastante útil em vários cenários de data warehouse. Melhorias virão nas próximas versões.
9) JSON: o suporte a esse tipo de dado foi incluída na versão 9.2 com promessa de melhorias nas versões subsequentes. Algumas das melhorias já vieram na 9.3 com a adição de várias funções e operadores para facilitar a manipulação de dados nesse formato.
10) psql: duas funcionalidades chamaram a minha atenção. A primeira delas é o novo comando \watch que torna possível a execução do último comando a cada n segundos (útil para algum monitoramento). A segunda é a saída formatada em LaTeX utilizando o pacote longtable (os meus relatórios esperavam ansiosamente por esta funcionalidade :-).
11) pg_dump: o pg_restore já suportava o paralelismo desde a versão 8.4; esta foi a vez do pg_dump. Pela falta de um mecanismo para exportar a snapshot (para que todos os processos de trabalho possam "enxergar" os mesmos dados) e um formato (de diretório) que pudesse armazenar objetos individuais (vários arquivos), o pg_dump tinha que ser executado por somente um processo. Como no pg_restore, você poderá especificar a opção --jobs para distribuir a carga do pg_dump entre vários processos auxiliares e realizar cópias de segurança em um tempo menor.
12) processos de trabalho: conhecido como background workers, permitirá o desenvolvimento de processsos auxiliares (que são processos filho do postgres). Isso quer dizer que podemos desenvolver um agendador, manipulador de requisições e quaisquer outras tarefas auxiliares ao PostgreSQL. A ideia ter algo integrado ao SGBD.
(*) se alguém da impressa estiver interessado em produzir algum texto ou mesmo pedir orientação/revisão sobre o lançamento da 9.3, entre em contato comigo (que sou o contato regional).
