Neste dia, o código e as características congeladas estão se aproximando da versão 7.4. Esta é a boa notícia. A má notícia é que as características mais requisitadas e de maior risco, provavelmente não farão parte desta versão. Esta lista inclui:

• Suporte nativo ao Windows
• Replicação
• Recuperação em múltiplos pontos de salvamento (Point in Time)
• Transações aninhadas

Segurando a versão por causa de recursos, tem resultado na insatisfação de muitas pessoas e em algumas versões atrasadas. É determinante que nós possamos liberar os recursos que já estão disponíveis. Muitas pessoas estão aguardando por recursos completos também.

Na discussão sobre a versão 7.4 na lista hackers, há ótimos comentários sobre as novas características da versão 7.4.

Rod Taylor

Um rápido relance na lista de tarefas a serem feitas (TODO list) mostra um número de melhorias de velocidade em áreas específicas (IN, GROUP BY, subconsultas em visões), melhorias em vetores (ARRAY), melhorias / adições em alguns comandos utilitários, e uma atualização significante no protocolo.

A atualização do protocolo pode não ser algo espalhafatoso, mas é um enorme passo adiante na apresentação clara de experiências para desenvolvedores que usam o PostgreSQL (reduzindo as chances de encontrar raros, inesperados e dificultosos erros lógicos).

...isto cria uma excelente versão depurada que completa alguns pontos bem definidos (complementação automática para elementos de esquema no psql com a tecla tab, extração do esquema no psql, suporte à agrupamentos fixos (fixed cluster), truncamento transacional, alterar seqüência, novo código regex para manipulação de MultiByte mais rápido, etc).

[O] problema do crescimento do índice [é] resolvido nesta versão. Eu acho que é um recurso "matador" que resolve um grande número de problemas para muita gente.

Nós temos um grande número de coisas muito boas. Você não está satisfeito com a notícia de que a performance do IN (subconsulta) tenha sido corrigida? Aquele índice do tipo btree inchado está corrigido (pelo menos uma grande parte, ainda falta para ser visto se a performance do campo é tudo o que precisamos...)?

Na minha opinião o projeto não está num estado onde novos Recursos instantâneos com R maiúsculo estão pulando por cima do trabalho laborial. Nós estamos conseguindo ótimos avanços em performance, confiabilidade, conformidade com as especificações SQL, e coisas desse tipo, mas tópicos que soam estravagantes são difíceis de vir.

Eu posso dizer à vocês que o grupo CCM da Red Hat (o antigo Ars Digita) está esperando... pela versão 7.4, porque eles corrigem um grande número de problemas (IN-subconsulta foi um deles) que impediu a versão 7.3 de se tornar um sério concorrente ao Oracle para a plataforma deles.

Eu acho que o trabalho do vacuum automático (auto vacuum) será enorme, e pessoalmente, acho que gatilhos (triggers) em nível de declarações são muito importantes também.

Eu não tenho certeza se o tsearch do diretório contrib é um recurso "matador", mas nós esperamos disponibilizar por completo uma nova versão do tsearch V2 antes de 1º de Julho.

Nós não devemos esquecer da disponibilidade de produtos de parceiros do PostgreSQL, como pgAdmin3 e phpPgAdmin3. [Há rumores que] estas duas Interfaces Gráficas de Usuário (GUI) estarão prontas para serem liberadas no mês de Julho.

• -Adicionar programação de tempo para início do pg_stat_activity
• -Alterar o tipo de dado NUMERIC para usar base 10000 internamente
• -Adicionar variáveis GUC para controlar os dígitos de saída de números de ponto flutuante (Pedro Ferreira)
• -Possibilitar segurança transacional ao TRUNCATE (Rod)
• -Adicionar a cláusula SET WITHOUT OIDS na declaração ALTER TABLE (Rod)
• -Adicionar a possibilidade de ALTER SEQUENCE modificar os valores dos atributos min/max/increment/cache/cycle
• -Permitir à CLUSTER agrupar todas as tabelas (Alvaro Herrera)
• -MOVE 0 não deve mover o ponteiro para o fim do cursor de registros (Bruce)
• -Permitir cursores fora de transações
• -Tornar a cláusula %TYPE do PL/PgSQL disponível para esquemas (schema)
• -Adicionar esquema (schema), alteração de tipos (cast) e conversões, em comandos de barra invertida no psql (Christopher)
• -Permitir ao pg_dump para extrair um esquema específico (Neil Conway)
• -Suportar gatilhos (triggers) à nível de declarações (Neil)
• -Adicionar a opção checkpoint_min_warning ao arquivo postgresql.conf para alertar sobre pontos de checagem (checkpoints) que aparecem freqüentemente (Bruce)
• -Adicionar tecnologia hash para avaliar funções agregadas de GROUP BY (Tom)
• -Fazer com que IN/NOT IN tenham performance equivalente à EXISTS/NOT EXISTS (Tom)
• -Enfileirar funções simples em SQL para evitar estouro de pilha (overhead) (Tom)
• -Conseguir o código de um regex() mais rápido com Henry Spencer
• -Alterar testes de regressão para prevenir falhas que acontecem por causa de arredondamentos numéricos mínimos
• -Adicionar a chamada da função getpeereid() do OpenBSD para autenticação no soquete (socket) local
• e muitas correções de erros.

Colaboradores: Bruce Momjian pgman em candle.pha.pa.us, Christopher Kings-Lynne chriskl em familyhealth.com.au, Rod Taylor rbt em rbt.ca, Matthew T. O'Connor matthew em zeut.net, Alvaro Herrera alvherre em dcc.uchile.cl, Tom Lane tgl em sss.pgh.pa.us, Robert Treat xzilla em users.sourceforge.net, Andrew Dunstan andrew em dunslane.net, Oleg Bartunov oleg em sai.msu.su, Jean-Michel POURE jm.poure em freesurf.fr, Josh Berkus josh em agliodbs.com, Bruno Wolff III bruno em wolff.to, greg em turnstep.com

Quando utilizamos o comando de junção JOIN em uma consulta, temos o controle sobre a ordem do JOIN. Isso é muito bom no caso de você possuir informações que não estão disponíveis para o planejador (planner - processo de planejamento de execução da consulta) -- e freqüentemente você tem estas informações, principalmente quando há várias tabelas na consulta.

Quando você junta tabelas usando a cláusula WHERE, o planejador faz a junção ordenando com base em todas as informações que ele tem. O planejador é exponencialmente lento para cada tabela adicional na junção. No entanto, o planejador é realmente bom em escolher o melhor plano de execução.

Na versão 7.4, o comando JOIN também terá em suas mãos a responsabilidade pela ordem da junção para que o planejador, ao mesmo tempo, expanda o controle sobre os tipos de junções com a cláusula WHERE. As variáveis from_collapse_limit e join_collapse_limit irão limitar as considerações feitas pelo planejador sobre a utilização de múltiplas tabelas para, digamos uma, quando você estiver usando instruções JOIN conhecidas e testadas ou, somente usando múltiplas tabelas na cláusula FROM na sua consulta.

Colaboradores: culley harrelson culley em fastmail.fm, Bruno Wolff III bruno em wolff.to, Tom Lane tgl em sss.pgh.pa.us

Retirar erros de uma função em linguagem C pode ser frustrante se você não conhece a seqüencia dos eventos e das ferramentas disponíveis.

Para nexar o gdb ao servidor na intenção de retirar erros das suas funções, primeiro você deve ter certeza que a biblioteca compartilhada à qual contém sua função está carregada no servidor. O objeto compartilhado não é carregado até que ele seja necessário, então, você precisa forçar o carregamento como sendo a primeira chamada, especialmente se uma chamada qualquer fazer o servidor cair.

Uma vez que a biblioteca compartilhada estiver carregada, então você pode anexá-la ao processo do servidor com gdb. O exemplo que Tom Lane nos dá é:

	inicie uma nova sessão
	psql=> LOAD 'libraryname';
	anexe ao processo do servidor com gdb
	gdb> b myfunc
	gdb> cont
	psql=> SELECT myfunc();

Se isto não funcionar, você talvez terá que dizer ao gdb sobre as bibliotecas compartilhadas. Edite o comando sharedlibrary no gdb para forçá-lo a absorver as definições dos símbolos da shlib.

Uma alternativa tradicional é usar declarações elog(DEBUG...) (ou printf()s) para apresentar qual ponto (status) da função está sendo executado. A função printf() apresenta somente no dispositivo padrão de saída, por exemplo, seu arquivo de acompanhamento (log). (Você não está enviando seu arquivo de acompanhamento para /dev/null, não é?). Usar elog( WARNING, ...); pode ser também muito esclarecedor, apresentando algo antes de cair (a função ser interrompida por um erro).

E claro, nenhuma ferramenta ou processo é melhor do que uma revisão no código ou pelo menos um segundo par de olhos conhecedores.

Colaboradores: Nigel J. Andrews nandrews em investsystems.co.uk, Tom Lane tgl em sss.pgh.pa.us, Peter Eisentraut peter_e em gmx.net, elein em varlena.com

Em uma tabela onde a chave primária é composta, você deve sempre se referir à chave composta inteira em uma referência de chave estrangeira. A tabela abaixo é definida tendo as duas primeiras colunas como chave primária.

	CREATE TABLE foo (
		col_one		integer,
		col_two		integer,
		col_three	text,
		col_four		text,
		PRIMARY KEY (col_one, col_two) );

	CREATE TABLE bar (
		col_a	integer,
		col_b	integer,
		col_c	text,
	FOREIGN KEY (col_a, col_b)
	REFERENCES foo (col_one, col_two));

Se por acaso, a tabela foo possuísse a coluna col_one com sendo única (sem repetições), você precisaria definir somente esta coluna como chave primária. E se você quisesse um índice sobre as três colunas, você poderia criá-lo separadamente.

Uma chave primária é aquela que é designada como chave primária e possui as seguintes restrições: é única e não nula. Você pode ter diversas chaves candidatas, com uma única ou um grupo de colunas, às quais satisfazem estes critérios. No entanto, somente uma chave candidata pode ser designada como chave primária.

Você pode criar chaves estrangeiras para qualquer chave candidata, seja para uma chave primária definida ou não. Contudo, se a sua chave candidata faz parte de uma chave composta, voce ainda deverá usar todos os elementos da chave composta na referência da sua chave estrangeira.

Colaboradores: Reuben D. Budiardja techlist em voyager.phys.utk.edu, Gianni Mariani gianni em mariani.ws, Mark Wilson mwilson13 em cox.net

Ao criar um arquivo de dados e informações extraídas do banco através do pg_dump com o comando abaixo, você deve ter certeza de descompactá-lo antes de restaurar o arquivo resultante: pgdump_2003-6-5-csp.gz. Caso tenha compactado, você precisa descompactá-lo.

/usr/local/pgsql/bin/pg_dump $db | gzip > /usr/local/pgsql/backups/$filename

Há dois métodos a serem usados para restaurar arquivos extraídos do banco produzidos pelo pg_dump dependendo se foi ou não chamado com as opções de compressão -Fc ou -Ft.

Se voce usar o pg_dump sem as opções de compressão os dados e informações extraídos do banco serão texto puro com a formatação SQL. A restauração é efetuada utilizando o pgsql

pgsql -f pgdump_2003-6-5-csp

Colaboradores: Brian Avis brian.avis em searhc.org Steve Lane slane em moyergroup.com Tom Lane tgl em sss.pgh.pa.us Jeff Fitzmyers jeff em cloverpub.com Murthy Kambhampaty murthy.kambhampaty em goeci.com btober em seaworthysys.com Doug McNaught doug em mcnaught.org Peter Eisentraut peter_e em gmx.net Richard Huxton dev em archonet.com scott.marlowe scott.marlowe em ihs.com