Por padrão o PostgreSQL vem configurado para receber apenas conexões locais (localhost ou 127.0.0.1). Para conectar de outra máquina na rede é preciso alterar algumas configurações básicas em 2 arquivos.

São eles: postgresql.conf e pg_hba.conf.

No postgresql.conf vamos editar a seguinte linha:

#listen_addresses = ‘localhost’ # what IP address(es) to listen on

Como em todo arquivo de configuração em programas linux, o # na frente da linha significa um comentário e com isso desabilita o parâmetro seguinte, tomando seu valor default, que no caso é localhost. Descomente essa linha e substitua seu valor por *. Assim seu PostgreSQL estará apto a ouvir conexões de qualquer IP.Então essa linha ficará da seguinte forma:

listen_addresses = ‘*‘ # what IP address(es) to listen on

Isso não quer dizer que ele estará aberto para qualquer IP da rede. É possível criar políticas de acesso através de outro arquivo que falaremos a seguir.

Liberando as conexões no arquivo pg_hba.conf:

Este é o arquivo do Postgre responsável pela liberação de usuários, hosts e bancos de dados. Nele é possível dizer qual usuário de qual ip (ou rede) conectará a qual banco. É possível liberar qualquer usuário para coenctar a qualquer banco, mas esta é uma regra cautelosa a ser seguida pois pode comprometer a segurança do seu servidor de bases de dados.

Por padrão o arquivo vem com a seguinte configuração:

# “local” is for Unix domain socket connections only
local   all         all                                              trust
# IPv4 local connections:
host    all         all         127.0.0.1/32          trust
# IPv6 local connections:
host    all         all         ::1/128                      trust

Pode haver alguma variação das configurações padrões de acordo com a versão utilizada, mas geralmente é algo que represente essas informações. Basicamente elas querem dizer que todas as conexões locais podem ser realizadas por qualquer usuário do banco a qualquer banco de dados.

Para liberar o acesso remoto basta criar uma nova regra seguindo o seguinte padrão:

host    all         all        0.0.0.0/0               trust

Com essa regra qualquer usuário de qualquer IP poderá se conectar a qualquer database.
Importante: O parâmetro trust quer dizer que não será solicitada qualquer senha para conectar ao banco de dados. Então, qualquer pessoa com acesso à sua rede poderá se conectar ao servidor PostgreSQL sem nenhuma restrição. Se a sua rede for restrita como uma turma de um curso ou um ambiente de desenvolvimento interno de empresa não há riscos, porém, é necessário possuir um ambiente de rede interno isolado.

Este parâmetro é útil quando você ainda não se conectou ao banco para criar uma senha de acesso ao usuário postgres (do banco e não do sistema operacional). Então você se conecta e reseta a senha do usuário. Logo em seguida, altere o parâmetro para md5. Assim, uma senha será solicitada ao tentar conectar-se ao servidor Postgre.

Assim ficará a regra de liberação:

host    all all 0.0.0.0/0               md5

É possível também liberar o acesso apenas a uma rede específica:

host    all all 192.168.0.0/32 md5

Ou também, informar qual usuário poderá conectar:

host    all usuariodobanco 192.168.0.0/32 md5

Também informar qual o banco de dados a ser conectaro por este usuário:

host    bancodedados usuariodobanco 192.168.0.0/32 md5

Na regra acima, o usuário usuariodobanco poderá conectar-se apenas ao banco bancodedados apenas se estiver dentro da rede 192.168.0.0.

Em breve escreverei outro post falando um pouco mais sobre as regras do pg_hba.conf.

Obrigado e espero que gostem!

Agora falaremos sobre como habilitar a linguagem PLPGSQL em nosso banco de dados.

Antes de tudo é necessário ser o dono do banco de dados referente ou entrar como postgres para poder mexer em qualquer base do servidor Postgre.

Feito isso, rodamos o seguinte comando para liberar a linguagem:

CREATE TRUSTED PROCEDURAL LANGUAGE 'plpgsql'
 HANDLER plpgsql_call_handler
 VALIDATOR plpgsql_validator;

Pronto, nossa linguagem está criada.

É recomendado que este comando seja executado no banco de dados template1 para a linguagem plpgsql ser inclúida como default em novos bancos de dados criados no servidor.

Agora é só aproveitar os novos recursos disponíveis e botar a mão na massa!

Aproveitem!

Quando compilamos um PostgreSQL no servidor, por padrão o DBLINK assim como muitos outros contribs não vem habilitado por padrão. Mas é muito simples liberar essa excelente funcionalidade em nosso banco.

Na pasta do source do Postgre existe uma psta contrib e dentro dela, a pasta dblink.

É válido lembrar que esse procedimento será possível apenas se você possuir controle do servidor como root ou sudo. Caso não possua ou estiver utilizando um provedor de hospedagem será necessário solicitar a liberação do recurso pelos administradores.

O diretório do dblink será mais ou menos assim:

Listagem de diretório dblink

O processo de compilação é simples. Uma vez dentro do diretório, basta rodar os comandos:

make

e depois

make install

Após a mensagem de sucesso, o contrib já estará disponível no servidor, porém, ainda não disponível para usar no seu banco de dados. Para isso é preciso adicionar as funções do dblink ao seu banco.

Como root execute o seguinte comando (onde seubancodedados corresponde ao nome da sua base):

psql -U postgres seubancodedados < dblink.sql

Isso criará uma série de functions dentro do seu banco como no exemplo abaixo:

Pronto! O dblink está habilitado em seu banco de dados. É recomendado seguir o último passo apontando para o banco de dados template1. Isso fará com que todos os novos bancos de dados sejam criados já com as funções dblink dentro habilitadas.

psql -U postgres template1 < dblink.sql

Em outro post falarei como utilizar as funções do dblink.

Por padrão o PostgreSQL vem configurado para receber apenas conexões locais (localhost ou 127.0.0.1). Para conectar de outra máquina na rede é preciso alterar algumas configurações básicas em 2 arquivos.

São eles: postgresql.conf e pg_hba.conf.

No postgresql.conf vamos editar a seguinte linha:

#listen_addresses = ‘localhost’ # what IP address(es) to listen on

Como em todo arquivo de configuração em programas linux, o # na frente da linha significa um comentário e com isso desabilita o parâmetro seguinte, tomando seu valor default, que no caso é localhost. Descomente essa linha e substitua seu valor por *. Assim seu PostgreSQL estará apto a ouvir conexões de qualquer IP.Então essa linha ficará da seguinte forma:

listen_addresses = ‘*‘ # what IP address(es) to listen on

Isso não quer dizer que ele estará aberto para qualquer IP da rede. É possível criar políticas de acesso através de outro arquivo que falaremos a seguir.

Liberando as conexões no arquivo pg_hba.conf:

Este é o arquivo do Postgre responsável pela liberação de usuários, hosts e bancos de dados. Nele é possível dizer qual usuário de qual ip (ou rede) conectará a qual banco. É possível liberar qualquer usuário para coenctar a qualquer banco, mas esta é uma regra cautelosa a ser seguida pois pode comprometer a segurança do seu servidor de bases de dados.

Por padrão o arquivo vem com a seguinte configuração:

# “local” is for Unix domain socket connections only
local all all trust
# IPv4 local connections:
host all all 127.0.0.1/32 trust
# IPv6 local connections:
host all all ::1/128 trust

Pode haver alguma variação das configurações padrões de acordo com a versão utilizada, mas geralmente é algo que represente essas informações. Basicamente elas querem dizer que todas as conexões locais podem ser realizadas por qualquer usuário do banco a qualquer banco de dados.

Para liberar o acesso remoto basta criar uma nova regra seguindo o seguinte padrão:

host all all 0.0.0.0/0 trust

Com essa regra qualquer usuário de qualquer IP poderá se conectar a qualquer database.
Importante: O parâmetro trust quer dizer que não será solicitada qualquer senha para conectar ao banco de dados. Então, qualquer pessoa com acesso à sua rede poderá se conectar ao servidor PostgreSQL sem nenhuma restrição. Se a sua rede for restrita como uma turma de um curso ou um ambiente de desenvolvimento interno de empresa não há riscos, porém, é necessário possuir um ambiente de rede interno isolado.

Este parâmetro é útil quando você ainda não se conectou ao banco para criar uma senha de acesso ao usuário postgres (do banco e não do sistema operacional). Então você se conecta e reseta a senha do usuário. Logo em seguida, altere o parâmetro para md5. Assim, uma senha será solicitada ao tentar conectar-se ao servidor Postgre.

Assim ficará a regra de liberação:

host all all 0.0.0.0/0 md5

É possível também liberar o acesso apenas a uma rede específica:

host all all 192.168.0.0/32 md5

Ou também, informar qual usuário poderá conectar:

host all usuariodobanco 192.168.0.0/32 md5

Também informar qual o banco de dados a ser conectaro por este usuário:

host bancodedados usuariodobanco 192.168.0.0/32 md5

Na regra acima, o usuário usuariodobanco poderá conectar-se apenas ao banco bancodedados apenas se estiver dentro da rede 192.168.0.0.

Em breve escreverei outro post falando um pouco mais sobre as regras do pg_hba.conf.

Obrigado e espero que gostem!

Problema:
Como fazer buscas em banco de dados ignorando letras maiusculas/minusculas?

Geralmente os SGBDs são case sensitive e é muito comum recorrermos a alternativas para transformar os textos na hora de comparar valores do banco case sensitive em consultas que fazemos.

Exemplo de uma query comum:

SELECT * FROM cliente WHERE nome LIKE ‘%Marcelo%’;

Nessa query, retornarão apenas clientes que possuam Marcelo (com M maiúsculo) no nome. Se o valor consultado estivesse em letras minúsculas (marcelo), ignoraria todos os nomes em maiúsculos cadastrados no banco.

Alternativa Padrão:

Algumas pessoas passaram a utilizar a função UPPER para eliminar esse problema:

SELECT * FROM cliente WHERE UPPER(nome) LIKE ‘%’ || UPPER(‘Marcelo’) || ‘%’;

Nesse caso, o valor armazenado na coluna nome será transformado para CAIXA ALTA e o mesmo acontecerá para o valor consultado. No caso, o valor Marcelo será transformado para MARCELO.

Isso funciona até certo ponto, pois essa função não converte letras acentuadas e caracteres especiais. No caso, João seria transformado para JOãO. Creio que esse não é o nosso objetivo, nesse caso.

Eis a solução para o problema:

Sendo assim, a melhor alternativa para esse caso seria usar o termo “~*” (til + asterístico). Nesse caso, o Postgre automaticamente procura por qualquer ocorrência do valor pesquisado, ignorando o case sensitive.

SELECT * FROM cliente WHERE nome ~* ‘Marcelo’;

Essa técnica funciona em PostgreSQL e MySQL mas nunca testei no Oracle ou MSSQL. Quem experimentar pode compartilhar conosco o resultado com comentários.

Pesquise por hospedagens de sites com MySQL e PostgreSQL