PL/SQL no PostgreSQL
PLSQL no PostgreSQL é um dos principais temas para empresas que avaliam a migração de aplicações Oracle para uma plataforma PostgreSQL Enterprise. Em ambientes corporativos, grande parte da lógica de negócio pode estar armazenada diretamente no banco de dados por meio de procedures, functions, triggers, packages, cursores, exceções e outros componentes desenvolvidos em PL/SQL.
Para organizações que desejam modernizar aplicações Oracle sem reescrever todo o código do banco desde o início, a compatibilidade oferecida pelo EDB Postgres Advanced Server pode reduzir significativamente o esforço de conversão. A EDB disponibiliza uma linguagem procedural própria, denominada SPL, que oferece recursos de compatibilidade para desenvolvimento de procedures, functions, triggers e packages e foi projetada para facilitar a execução e migração de aplicações Oracle. Documentação oficial da EDB.
Isso não significa que todo código PL/SQL possa ser transferido sem análise. O nível de compatibilidade depende dos recursos utilizados pela aplicação, da versão do ambiente de origem, das dependências existentes e dos requisitos funcionais e de desempenho. A própria EDB destaca que o EDB Postgres Advanced Server não implementa todos os recursos do Oracle, embora disponibilize compatibilidade com muitos dos construtos mais utilizados. EDB — recursos para migração Oracle.
O que é PL/SQL e qual é seu papel no PostgreSQL?
O que é PL/SQL?
PL/SQL é a linguagem procedural associada ao Oracle Database e é amplamente utilizada para implementar lógica de negócio diretamente no banco de dados.
Em aplicações corporativas, o código PL/SQL pode ser responsável por tarefas muito além de simples consultas.
- Validação de regras de negócio.
- Processamento de transações.
- Atualização de múltiplas tabelas.
- Processamento em lote.
- Rotinas de integração.
- Automação de tarefas.
- Auditoria.
- Tratamento de exceções.
- Geração de informações.
- Processos financeiros.
- Processos administrativos.
- Procedimentos de fechamento e consolidação.
Por esse motivo, uma migração Oracle para PostgreSQL precisa analisar o código procedural como parte central do projeto.
PL/SQL pode estar no centro da aplicação
Em sistemas desenvolvidos ao longo de muitos anos, a lógica de negócio pode estar distribuída entre a camada da aplicação e o banco de dados.
Em determinados ambientes, uma quantidade significativa das regras pode estar implementada em packages, procedures e functions.
Reescrever todo esse código antes mesmo de validar a viabilidade da migração pode aumentar consideravelmente o prazo, o custo e o risco do projeto.
PL/SQL no PostgreSQL Enterprise
O PostgreSQL comunitário possui sua própria arquitetura de linguagens procedurais e extensões, mas não tem como objetivo reproduzir integralmente o comportamento do PL/SQL Oracle.
O EDB Postgres Advanced Server adiciona recursos de compatibilidade Oracle ao PostgreSQL, incluindo uma linguagem procedural denominada SPL.
A documentação oficial da EDB descreve o SPL como uma linguagem procedural utilizada para criar procedures, functions, triggers e packages no EDB Postgres Advanced Server. Referência oficial do SPL.
O objetivo da compatibilidade
O objetivo não é transformar PostgreSQL em Oracle.
O objetivo é oferecer uma camada de compatibilidade capaz de reduzir a quantidade de alterações necessárias durante a modernização de aplicações Oracle.
Para uma empresa que possui uma grande base instalada Oracle, essa diferença de abordagem pode ser estratégica.

SPL, procedures e functions
SPL no EDB Postgres Advanced Server
O Stored Procedural Language, conhecido como SPL, é um dos componentes centrais da estratégia de compatibilidade Oracle do EDB Postgres Advanced Server.
A documentação oficial descreve o SPL como uma linguagem comum para criação de stored procedures, functions, triggers e packages. A linguagem inclui estruturas de controle, declarações de variáveis, tratamento de exceções, cursores, SQL dinâmico, coleções e outros recursos necessários para desenvolvimento de lógica no servidor. Documentação oficial — Using the stored procedural language.
Procedures
Procedures são utilizadas para encapsular operações que podem ser executadas diretamente no banco de dados.
Durante uma migração Oracle, uma procedure pode conter:
- Regras de negócio.
- Atualizações de dados.
- Validações.
- Chamadas a outras procedures.
- Chamadas a functions.
- Controle transacional.
- Tratamento de exceções.
- SQL dinâmico.
- Processamento de múltiplos registros.
O suporte a procedures compatíveis permite que a equipe avalie a possibilidade de preservar parte dessa lógica em vez de reescrevê-la integralmente.
Functions
Functions podem ser utilizadas tanto pela aplicação quanto diretamente em consultas SQL.
Uma function pode realizar cálculos, validações, transformação de dados ou encapsular regras de negócio.
Em um projeto de migração, é necessário verificar não apenas se a function pode ser convertida, mas também se seu comportamento continua equivalente no ambiente de destino.
Parâmetros de procedures e functions
Aplicações Oracle podem utilizar diferentes formas de passagem de parâmetros.
O SPL disponibiliza mecanismos para trabalhar com parâmetros posicionais e nomeados, além de diferentes modos de parâmetros.
Esse tipo de compatibilidade pode ser importante para aplicações que fazem chamadas complexas a procedures e functions.
IN, OUT e INOUT
Durante o assessment, é importante identificar procedures que utilizam parâmetros de entrada, saída e entrada/saída.
Essas dependências devem ser validadas também na camada da aplicação, principalmente quando a chamada é realizada por drivers ou frameworks que possuem tratamento específico para parâmetros Oracle.
Subprocedures e subfunctions
Aplicações corporativas podem utilizar subprocedures e subfunctions para organizar a lógica interna de uma procedure ou function.
A documentação do SPL inclui suporte a subprogramas, incluindo subprocedures, subfunctions, declarações antecipadas e sobrecarga de subprogramas. EDB — SPL Reference.
Esse conjunto de recursos pode ser relevante durante a conversão de aplicações Oracle com grande quantidade de lógica procedural.
Recursos avançados de PL/SQL
Cursores no PostgreSQL compatível com Oracle
Cursores são frequentemente utilizados em aplicações procedurais para processar conjuntos de registros de maneira controlada.
O SPL oferece suporte a cursores estáticos, REF CURSOR e variáveis de cursor.
Isso permite trabalhar com padrões de programação comuns em aplicações Oracle.
REF CURSOR
REF CURSOR pode ser utilizado para retornar conjuntos de resultados entre componentes da aplicação e o banco de dados.
Em uma migração, é necessário validar a forma como esses cursores são consumidos pelos drivers e pela aplicação.
SQL dinâmico
Aplicações corporativas frequentemente utilizam SQL dinâmico para montar comandos em tempo de execução.
Esse recurso pode aparecer em procedures, functions, packages e processos administrativos.
O SPL possui suporte a SQL dinâmico, permitindo reproduzir determinados padrões utilizados em aplicações Oracle. EDB — Using the stored procedural language.
Por que SQL dinâmico exige atenção?
SQL dinâmico pode ser mais difícil de analisar automaticamente porque o comando final pode ser construído durante a execução.
Por isso, um assessment precisa identificar não apenas o código SQL estático, mas também os comandos montados dinamicamente.
Tratamento de exceções
O tratamento de exceções é parte importante da lógica procedural.
Uma aplicação pode depender de comportamentos específicos para tratar erros, realizar rollback, registrar ocorrências ou executar procedimentos alternativos.
Durante a migração, as exceções devem ser testadas funcionalmente e não apenas verificadas em relação à sintaxe.
Erros e comportamento da aplicação
Uma rotina pode compilar corretamente e ainda apresentar comportamento diferente quando ocorre uma condição excepcional.
Por isso, os testes devem incluir cenários de erro e não apenas o fluxo de execução normal.
Coleções e tipos compostos
O SPL também possui recursos para trabalhar com coleções e estruturas de dados utilizadas pela lógica procedural.
Esses recursos podem ser importantes em aplicações Oracle que utilizam arrays, records, coleções e estruturas equivalentes.
A documentação oficial do SPL possui uma seção específica para tipos de coleção e métodos de coleção. EDB — SPL Reference.

Migração de PL/SQL para PostgreSQL
Como migrar PL/SQL para PostgreSQL?
A migração de PL/SQL para PostgreSQL deve começar por um assessment detalhado da aplicação.
O primeiro objetivo é descobrir quanto código procedural existe e qual é o nível de dependência do Oracle.
Etapa 1 — Inventário do código
O inventário deve identificar:
- Quantidade de procedures.
- Quantidade de functions.
- Quantidade de packages.
- Quantidade de triggers.
- Quantidade de linhas de código.
- Dependências entre objetos.
- Uso de SQL dinâmico.
- Uso de cursores.
- Uso de exceções.
- Dependências de packages Oracle.
- Dependências de tipos Oracle.
Etapa 2 — Classificação de compatibilidade
Depois do inventário, os objetos podem ser classificados de acordo com o esforço esperado.
- Compatível: código que pode ser executado ou adaptado com pequenas alterações.
- Conversível: código que exige ajustes estruturais, mas preserva a lógica original.
- Reengenharia: código que depende fortemente de recursos específicos do Oracle.
- Substituição: componentes que podem ser melhor implementados utilizando recursos nativos do PostgreSQL.
EDB Migration Toolkit
O EDB Migration Toolkit faz parte do conjunto de ferramentas disponibilizado pela EDB para apoiar projetos de migração.
Ele pode ser utilizado em processos relacionados à transferência de objetos e dados entre bancos de dados, enquanto outras ferramentas da EDB auxiliam na análise e conversão de ambientes Oracle.
Para a análise específica do código PL/SQL, entretanto, a equipe deve considerar também as ferramentas de assessment e os recursos de compatibilidade do EDB Postgres Advanced Server.
Migration Portal
O Migration Portal da EDB pode analisar DDL Oracle e identificar elementos que precisam de conversão, oferecendo informações úteis para estimar o esforço de migração.
Esse tipo de ferramenta é particularmente útil para transformar um projeto de migração em uma atividade mensurável.
Packages Oracle
Packages merecem uma análise específica porque podem concentrar grande quantidade de lógica.
O EDB Postgres Advanced Server fornece packages compatíveis com Oracle, incluindo diversos componentes conhecidos do ecossistema Oracle.
A documentação oficial atual lista, entre outros, DBMS_SQL, DBMS_OUTPUT, DBMS_SCHEDULER, DBMS_JOB, DBMS_LOB, DBMS_LOCK, DBMS_RANDOM, DBMS_UTILITY, UTL_FILE, UTL_HTTP e UTL_MAIL. EDB — Built-in packages.
Nem todo package deve ser tratado da mesma maneira
A existência de um package compatível não significa que todos os seus procedimentos tenham exatamente o mesmo comportamento ou que todas as dependências da aplicação estejam automaticamente resolvidas.
O correto é identificar quais funções e procedures do package são realmente utilizadas e testar esses fluxos na plataforma de destino.
Testes de PL/SQL migrado
Os testes precisam reproduzir os cenários reais da aplicação.
- Execução normal.
- Execução concorrente.
- Tratamento de erros.
- Rollback.
- Commit.
- Processamento de grandes volumes.
- Execução de jobs.
- Chamadas entre packages.
- Integração com a aplicação.
- Desempenho.
O objetivo é comprovar que a lógica migrada continua produzindo os resultados esperados.
Quando preservar e quando reescrever?
Essa é uma decisão arquitetural importante.
Em alguns casos, preservar a lógica existente pode reduzir o risco e acelerar a migração.
Em outros, aproveitar a migração para redesenhar componentes específicos pode produzir uma arquitetura mais simples e sustentável.
Preservar
Preservar tende a ser interessante quando o código é estável, bem conhecido, possui alto valor de negócio e apresenta boa compatibilidade com o ambiente de destino.
Reescrever
A reescrita pode ser considerada quando o componente depende fortemente de uma funcionalidade Oracle específica, possui problemas de manutenção ou precisa ser modernizado independentemente da mudança do banco de dados.
PL/SQL como estratégia de redução de risco
A compatibilidade com PL/SQL pode ser especialmente importante em projetos de modernização nos quais o maior risco não está nos dados, mas no código que implementa as regras de negócio.
Ao reduzir a quantidade de código que precisa ser reescrito, uma plataforma compatível pode permitir que a equipe concentre esforços nos componentes realmente críticos.
Isso pode transformar uma migração de grande escala em um projeto mais previsível, com fases de assessment, conversão, testes e transição.

Links relacionados, recursos oficiais e SEO
Links Relacionados
- Compatibilidade Oracle PostgreSQL
- PostgreSQL Compatível com Oracle
- Migração Oracle para PostgreSQL
- EnterpriseDB
- EDB Postgres Advanced Server
- EDB Migration Toolkit
- PostgreSQL Enterprise
- PostgreSQL para Empresas
- PostgreSQL vs EDB Postgres
- PostgreSQL Community vs EnterpriseDB
- EDB Replication Server
- EDB Failover Manager
- EDB Backup and Recovery
- EDB Control Center
- EDB Kubernetes
- EDB Distributed
Recursos Oficiais
- EDB — Database compatibility for Oracle developers
- EDB — Using the stored procedural language
- EDB — SPL Reference
- EDB — Built-in packages
- EDB — EDB capabilities for the migration journey
- EDB — SQL Reference

