Este blog é sobre a comunidade PostgreSQL, como ela funciona e qual a melhor forma de navegar nela. Observe que esta é apenas uma visão geral ... há muita documentação existente.
Visão geral da comunidade, como funciona o desenvolvimento
O PostgreSQL é desenvolvido e mantido por uma rede globalmente dispersa de voluntários altamente qualificados, apaixonados por computação de banco de dados relacional, conhecido como PostgreSQL Global Development Group. Um punhado de membros da equipe principal juntos lidam com responsabilidades especiais, como coordenar atividades de lançamento, comunicações internas especiais, anúncios de políticas, supervisionar privilégios de confirmação e a infraestrutura de hospedagem, questões disciplinares e outras questões de liderança, bem como responsabilidade individual pela codificação especializada, desenvolvimento e áreas de contribuição de manutenção . Cerca de quarenta indivíduos adicionais são considerados os principais contribuidores que, como o nome indica, realizaram atividades abrangentes de desenvolvimento ou manutenção para recursos significativos da base de código ou projetos intimamente relacionados. E várias dezenas de indivíduos estão fazendo várias outras contribuições ativamente. Além dos colaboradores ativos, uma longa lista de colaboradores anteriores é reconhecida pelo trabalho no projeto. É a habilidade e os altos padrões dessa equipe que resultaram no rico e robusto conjunto de recursos do PostgreSQL.
Muitos dos colaboradores têm empregos em tempo integral que se relacionam diretamente com o PostgreSQL ou outro software de código aberto, e o apoio entusiástico de seus empregadores torna viável seu envolvimento duradouro com a comunidade PostgreSQL.
Indivíduos contribuintes coordenam usando ferramentas de colaboração como Internet Relay Chat (irc://irc.freenode.net/PostgreSQL) e listas de discussão da comunidade PostgreSQL (https://www.PostgreSQL.org/community/lists). Se você é novo no IRC ou nas listas de discussão, faça um esforço especificamente para ler sobre etiqueta e protocolos (um bom artigo aparece em https://fedoramagazine.org/beginners-guide-irc/), e depois de entrar, gaste algum tempo apenas ouvindo conversas em andamento e pesquisando nos arquivos por perguntas semelhantes anteriores antes de entrar com seus próprios problemas.
Observe que a equipe não é estática:qualquer um pode se tornar um contribuidor, bem, contribuindo... mas sua contribuição deverá atender a esses mesmos altos padrões!
A equipe mantém uma página Wiki (https://wiki.postgresql.org/) que, entre muitas informações muito detalhadas e úteis como artigos, tutoriais, trechos de código e muito mais, apresenta uma lista TODO de bugs do PostgreSQL e solicitações de recursos e outras áreas onde o esforço pode ser necessário. Se você quer fazer parte da equipe, este é um bom lugar para navegar. Os itens são adicionados somente após uma discussão completa na lista de discussão do desenvolvedor.
A comunidade segue um processo, visualizado como as etapas na Figura 1.
Figura 1. Conceitualização do processo de desenvolvimento do PostgreSQL. Ou seja, espera-se que o valor de qualquer implementação de novo código não trivial seja primeiro discutido e considerado (por consenso) desejável. Em seguida, o investimento é feito em design:design da interface, sintaxe, semântica e comportamentos e consideração de problemas de compatibilidade com versões anteriores. Você deseja obter a adesão da comunidade de desenvolvedores sobre qual é o problema a ser resolvido e o que essa implementação realizará. Você definitivamente NÃO quer sair e desenvolver algo no vácuo por conta própria. Há literalmente décadas de experiência coletiva de altíssima qualidade incorporada à equipe, e você quer, e eles esperam, ter ideias avaliadas antecipadamente.
O código-fonte do PostgreSQL é armazenado e gerenciado usando o sistema de controle de versão Git, portanto, uma cópia local pode ser obtida em https://git.postgresql.org/ para iniciar a implementação. Observe que, para uma manutenção durável, os patches devem se misturar com o código ao redor e seguir as convenções de codificação estabelecidas (http://developer.postgresql.org/pgdocs/postgres/source.html), portanto, é uma boa ideia estudar qualquer código semelhante seções para aprender e emular as convenções. Geralmente, o estilo BSD de formato padrão é usado. Além disso, certifique-se de atualizar a documentação conforme apropriado.
O teste envolve primeiro garantir que os testes de regressão existentes sejam bem-sucedidos e que não haja avisos do compilador, mas também adicionar novos testes correspondentes para exercitar os recursos recém-implementados.
Quando a implementação da nova funcionalidade em seu repositório local estiver concluída, use a funcionalidade Git diff para criar um patch. Os patches são enviados por e-mail para a lista de discussão pgsql-hackers para revisão e comentários, mas você não precisa esperar até que seu trabalho esteja completo... uma prática inteligente seria pedir feedback de forma incremental. A página Wiki descreve as expectativas quanto ao formato e contexto explicativo útil e como mostrar respeito pelo tempo do revisor de código.
Os desenvolvedores do núcleo agendam periodicamente festivais de commit, durante os quais todos os patches não aplicados acumulados são adicionados ao repositório de código-fonte por committers autorizados. Como colaborador, seu código terá passado por uma revisão rigorosa e provavelmente suas próprias habilidades de desenvolvedor serão melhores para isso. Para retribuir o favor, há uma expectativa de que você dedique tempo para revisar os patches de outras pessoas.
Baixe o whitepaper hoje PostgreSQL Management &Automation with ClusterControlSaiba o que você precisa saber para implantar, monitorar, gerenciar e dimensionar o PostgreSQLBaixe o whitepaper
Principais sites para obter informações ou aprender PostgreSQL
| Site da comunidade - este é o principal local de lançamento da vida com o PostgreSQL | https://www.postgresql.org/ |
| Wiki - Tópicos abrangentes relacionados ao PostgreSQL | https://wiki.postgresql.org/ |
| Canal IRC - Os desenvolvedores são participantes ativos aqui | irc://irc.freenode.net/PostgreSQL |
| Repositório de código-fonte | https://git.postgresql.org/ |
| cliente GUI pgAdmin | https://www.pgadmin.org/ |
| Biografias de membros importantes da comunidade | https://www.postgresql.org/community/contributors/ |
| Famosa postagem de Eric Raymond sobre perguntas inteligentes | http://www.catb.org/esr/faqs/smart-questions.html |
| Controle de alteração do esquema do banco de dados | http://sqitch.org/ |
| Teste de unidade de banco de dados | http://pgtap.org/ |
As poucas ferramentas que você não pode viver sem
As ferramentas de linha de comando fundamentais para trabalhar com um banco de dados PostgreSQL fazem parte da distribuição normal. O cavalo de batalha é o utilitário de linha de comando psql, que fornece uma interface interativa com muitas funcionalidades para consultar, exibir e modificar metadados de banco de dados, bem como executar instruções de definição de dados (DDL) e manipulação de dados (DML).
Outros utilitários incluídos incluem pg_basebackup para estabelecer uma linha de base para backup baseado em replicação, pg_dump para extrair um banco de dados em um arquivo de script ou outro arquivo compactado, pg_restore para restaurar um arquivo pg_dump e outros. Todas essas ferramentas possuem excelentes páginas de manual, além de serem detalhadas na documentação padrão e inúmeros tutoriais on-line.
O pgAdmin é uma ferramenta de interface gráfica de usuário muito popular que fornece funcionalidade semelhante ao utilitário de linha de comando psql, mas com a conveniência de apontar e clicar. A Figura 2 mostra uma captura de tela do pgAdmin III. À esquerda está um painel mostrando todos os objetos de banco de dados no cluster no servidor host conectado. Você pode detalhar a estrutura para listar todos os bancos de dados, esquemas, tabelas, exibições, funções, etc., e até mesmo abrir tabelas e exibições para examinar os dados contidos. Para cada objeto, a ferramenta criará o SQL DML para descartar e recriar o objeto também, conforme mostrado no painel inferior direito. Essa é uma maneira conveniente de fazer modificações durante o desenvolvimento do banco de dados.
Figura 2. O utilitário pgAdmin III. Algumas das minhas ferramentas favoritas para equipes de desenvolvedores de aplicativos são o Sqitch (http://sqitch.org/), para controle de alterações de banco de dados, e o pgTAP (http://pgtap.org/). O Sqitch permite gerenciamento de mudanças autônomo e desenvolvimento iterativo por meio de scripts escritos no dialeto SQL nativo de sua implementação, não apenas PostgreSQL. Para cada alteração de design de banco de dados, você escreve três scripts:um para implementar a alteração, um para desfazer a alteração caso seja necessário reverter para uma versão anterior e um para verificar ou testar a alteração. Os scripts e arquivos relacionados podem ser mantidos em seu sistema de controle de revisão ao lado do código do aplicativo. PgTAP é uma estrutura de teste que inclui um conjunto de funcionalidades para verificar a integridade do banco de dados. Todos os scripts pgTAP são igualmente arquivos de texto simples compatíveis com os processos normais de gerenciamento de revisão e controle de alterações. Depois que comecei a usar essas duas ferramentas, achei difícil imaginar novamente fazer um trabalho de banco de dados sem.
Dicas e truques
A lista de discussão geral do PostgreSQL é a mais ativa das várias listas da comunidade e é a principal interface da comunidade para suporte gratuito aos usuários. Uma gama bastante ampla de perguntas aparece nesta lista, às vezes gerando longas idas e vindas, mas na maioria das vezes obtendo respostas rápidas, informativas e diretas.
Ao postar uma pergunta relacionada ao uso do PostgreSQL, você geralmente deseja sempre incluir informações básicas, incluindo a versão do PostgreSQL que você está usando (listado pela ferramenta de linha de comando psql com “psql --version”), o sistema operacional no qual o servidor está em execução e, em seguida, talvez uma descrição do ambiente operacional, como se pode ser predominantemente pesado de leitura ou de gravação, número típico de usuários e preocupações de simultaneidade, alterações feitas na configuração padrão do servidor (ou seja, o pg_hba.conf e postgresql.conf), etc. Muitas vezes, uma descrição do que você está tentando realizar é valiosa, em vez de alguma analogia obtusa, pois você pode obter sugestões de melhoria que você nem mesmo pensou por conta própria. Além disso, você obterá a melhor resposta se incluir DDL, DML e dados de amostra reais que ilustrem o problema e facilitem que outras pessoas recriem o que você está vendo - sim, as pessoas realmente executarão seu código de amostra e trabalharão com você.
Além disso, se você estiver perguntando sobre como melhorar o desempenho da consulta, deverá fornecer o plano de consulta, ou seja, a saída EXPLAIN. Isso é gerado executando sua consulta inalterada, exceto pelo prefixo literal com a palavra “EXPLAIN”, conforme mostrado na Figura 3 na ferramenta pgAdmin ou no utilitário de linha de comando psql.
Figura 3. Produzindo um plano de consulta com EXPLAIN. Em EXPLAIN, em vez de realmente executar a consulta, o servidor retorna o plano de consulta, que lista a saída detalhada de como a consulta será executada, incluindo quais índices serão usados para otimizar o acesso aos dados, onde as verificações de tabela podem ocorrer e estimativas do custo e quantidade de dados envolvidos em cada etapa. O tipo de ajuda que você receberá dos profissionais experientes que monitoram a lista de discussão pode identificar problemas e ajudar a sugerir possíveis novos índices ou alterações nos critérios de filtragem ou associação.
Por fim, ao participar de discussões de listas de discussão, há duas coisas importantes que você deve ter em mente.
Primeiro, o servidor de lista de e-mail é configurado para enviar mensagens configuradas para que, quando você responder, por padrão, seu software de e-mail responda apenas ao autor da mensagem original. Para ter certeza de que sua mensagem vai para a lista, você deve usar o recurso “responder a todos” do software de e-mail, que incluirá o autor da mensagem e o endereço da lista.
Segundo, a convenção nas listas de discussão do PostgreSQL é responder in-line e NÃO TOP POST. Este último ponto é uma convenção de longa data nesta comunidade, e para muitos recém-chegados parece tão incomum que advertências gentis são muito comuns. As opiniões variam sobre quanto da mensagem original deve ser retida para contextualizar sua resposta. Algumas pessoas se irritam com o crescimento, às vezes difícil, do tamanho da mensagem, quando toda a mensagem original é retida em muitas discussões de vai-e-vem. Eu, pessoalmente, gosto de excluir qualquer coisa que não seja relevante para o que estou respondendo especificamente para manter a mensagem concisa e focada. Apenas tenha em mente que há décadas de histórico de listas de discussão retidas on-line para documentação histórica e pesquisas futuras, portanto, manter o contexto e o fluxo é considerado muito importante.
Este artigo é para você começar, agora vá em frente e mergulhe!
