PostGIS Tiger Geocoder ganha versão 2025.2 e sai do core do PostGIS

A equipe de desenvolvimento do PostGIS anunciou a versão 2025.2 da extensão postgis_tiger_geocoder, publicada no Planet PostgreSQL↳PostgreSQL11 conteúdosPostgreSQL via SSL com GolangData · abr 20195 itens legais sobre data types do PostgreSQLData · mar 20195 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data →. Mais do que uma correção de bugs, o release confirma uma mudança estrutural importante: a extensão está deixando de fazer parte do núcleo do PostGIS e passa a viver com ciclo de vida próprio. Segundo a nota, esta é a segunda release desde a separação do PostGIS core.

O que é o Tiger Geocoder e por que ele importa

O postgis_tiger_geocoder é uma extensão escrita inteiramente em PL/pgSQL que transforma o PostgreSQL, com PostGIS instalado, em um serviço de geocodificação. Ela trabalha sobre os dados do TIGER/Line (o cadastro geográfico do U.S. Census Bureau) carregados no banco, permitindo converter endereços em coordenadas e vice-versa dentro de uma consulta SQL, sem depender de API externa.

A vantagem para quem cuida de dados é evidente: o geocoding acontece no mesmo lugar onde o dado espacial já reside, sob as mesmas regras de integridade, backup e controle de acesso do banco. Não há tráfego de endereços sensíveis para serviços de terceiros nem custo por requisição. Para uma aplicação que precisa geocodificar grandes volumes em lote, resolver isso com uma função SQL indexada costuma ser mais previsível do que orquestrar chamadas HTTP.

Vale registrar uma ressalva de escopo que o próprio modelo de versionamento evidencia: o Tiger Geocoder opera sobre a base TIGER dos Estados Unidos. O versionamento segue justamente o ano do dataset do Census vigente na data do release, daí a nomenclatura 2025.2. Para endereços brasileiros ele não serve diretamente; o interesse aqui é de arquitetura e de método, ou de empresas BR que precisam geocodificar bases americanas.

A separação do core do PostGIS

O ponto mais relevante deste anúncio é organizacional. A nota formaliza duas consequências práticas:

• A série PostGIS 3.6 é a última que inclui o postgis_tiger_geocoder.
• O PostGIS 3.7 será distribuído sem a extensão.

A partir de agora, o código tem repositório dedicado no Gitea da OSGeo, dentro da organização PostGIS. Quem depende do geocoder precisa incorporar essa nova fonte ao seu processo de instalação e atualização, em vez de simplesmente contar com o que vem no pacote do PostGIS.

Do ponto de vista de governança, a decisão faz sentido. O Tiger Geocoder está amarrado a um dataset que muda de ano em ano e tem público restrito frente ao universo do PostGIS. Separar seu ciclo de release do core evita que o cronograma do banco espacial fique preso a atualizações do Census e permite entregas mais ágeis a quem realmente usa a ferramenta. O outro lado do trade-off é que a extensão deixa de ser um componente garantido do stack: passa a exigir gestão explícita de dependência.

Requisitos e instalação

A versão 2025.2 exige PostgreSQL 16 ou superior e deve funcionar com qualquer versão suportada do PostGIS. Como a extensão é apenas PL/pgSQL, não há binários a compilar: caso não haja toolchain disponível, a distribuição oferece arquivos pré-construídos com prefixo postgis_tiger_geocoder-pg, que basta copiar para o diretório share/extension da instalação.

Para quem está atualizando de uma versão anterior, o caminho padrão é:

ALTER EXTENSION postgis_tiger_geocoder UPDATE;

Se o comando falhar com o erro extension "postgis_tiger_geocoder" has no update path from version "x" to version "2025.2", ou se a origem for uma versão de desenvolvimento, a nota recomenda forçar o caminho de atualização:

ALTER EXTENSION postgis_tiger_geocoder UPDATE TO "ANY";
ALTER EXTENSION postgis_tiger_geocoder UPDATE;

Esse tipo de detalhe merece atenção de qualquer DBA que administre bancos com a extensão em produção: o caminho de upgrade nem sempre é linear, e ter o plano de atualização testado em ambiente de homologação antes de tocar na produção continua sendo a conduta prudente.

As correções desta release

O changelog da 2025.2 é enxuto e concentrado em infraestrutura de build e empacotamento, o que é coerente com uma extensão que acabou de ganhar autonomia e ainda está estabilizando seu próprio pipeline:

• GT-35, correção do alvo de instalação (Devrim Gündüz);
• GT-38, correção de builds paralelos (Paul Ramsey);
• GT-40, qualificação de schema nas dependências da extensão (Regina Obe).

A correção GT-40 é a mais interessante do ponto de vista de robustez: qualificar por schema as dependências evita que a resolução de objetos dependa do search_path corrente, uma fonte clássica de comportamento inesperado e até de riscos de segurança em ambientes multi-schema. É o tipo de higiene que separa uma extensão amadora de uma pronta para produção.

O que fazer a partir daqui

Para quem já usa o Tiger Geocoder, o recado é claro: comece a tratá-lo como uma dependência externa gerenciada, não como algo que vem de brinde com o PostGIS. Isso significa acompanhar o repositório dedicado, documentar a origem dos arquivos de extensão no seu processo de provisionamento e planejar a migração antes de chegar ao PostGIS 3.7.

Para quem avalia adotar a ferramenta, ela continua sendo uma opção sólida de geocoding embutido no banco, com a ressalva já mencionada de que o dataset é americano. Em cenários de bases brasileiras, o valor está mais na arquitetura (geocoding dentro do PostgreSQL, sob as garantias transacionais do banco) do que na base de dados em si, que precisaria ser substituída por fontes nacionais equivalentes.

Fonte: Planet PostgreSQL