Esta seção lista os parâmetros de configuração que afetam o PL/Perl.
plperl.on_init (string)
#
Especifica o código Perl a ser
executado quando o interpretador Perl
é inicializado pela primeira vez, antes de ser ajustado para
uso pelo plperl ou plperlu.
As funções SPI não estão disponíveis quando este código é executado.
Se o código falhar com um erro, ele interromperá a inicialização
do interpretador, e se propagará para a consulta de chamada,
fazendo com que a transação ou subtransação corrente seja
interrompida.
O código Perl é limitado a uma única
cadeia de caracteres.
Um código mais longo pode ser colocado em um módulo, e carregado
pela cadeia de caracteres de on_init.
Exemplos:
plperl.on_init = 'require "plperlinit.pl"' plperl.on_init = 'use lib "/my/app"; use MyApp::PgInit;'
Quaisquer módulos carregados por plperl.on_init,
direta ou indiretamente, estarão disponíveis para uso pelo
plperl.
Isto pode criar um risco de segurança.
Para ver quais módulos foram carregados, pode ser usado:
DO 'elog(WARNING, join ", ", sort keys %INC)' LANGUAGE plperl;
A inicialização acontecerá no
postmaster, se a
biblioteca plperl estiver incluída em
shared_preload_libraries, caso em que uma
consideração extra deve ser dada ao risco de desestabilizar o
postmaster.
O principal motivo para usar este recurso, é que os módulos
Perl carregados por
plperl.on_init precisam ser carregados apenas
na inicialização do postmaster,
e estarão disponíveis instantaneamente, sem sobrecarga, em
sessões individuais do banco de dados.
Entretanto, deve-se ter em mente que a sobrecarga é evitada
apenas para o primeiro interpretador Perl
usado por uma sessão de banco de dados —
PL/PerlU ou
PL/Perl para a primeira função de
banco de dados
(identificador de autorização/role)
que chama uma função PL/Perl.
Qualquer interpretador Perl adicional
criado em uma sessão de banco de dados, terá que executar
plperl.on_init novamente.
Além disso, no Windows
não haverá nenhuma economia com o pré-carregamento, porque o
interpretador Perl criado no processo
postmaster não se propaga para os
processos filhos.
Este parâmetro só pode ser definido no arquivo
postgresql.conf, ou na linha de comando
do servidor.
plperl.on_plperl_init (string)
plperl.on_plperlu_init (string)
#
Estes parâmetros especificam o código
Perl
a ser executado quando o interpretador
Perl é ajustado para o
plperl ou o plperlu,
respectivamente.
Isto acontecerá quando uma função PL/Perl
ou PL/PerlU for executada pela primeira
vez em uma sessão de banco de dados, ou quando um interpretador
adicional tiver que ser criado, porque outra linguagem
é chamada, ou uma função PL/Perl
é chamada por uma nova função de banco de dados
(identificador de autorização/role).
Isto segue qualquer inicialização feita por
plperl.on_init.
As funções SPI não estão disponíveis quando este código é executado.
O código Perl em
plperl.on_plperl_init é executado após
“bloquear” o interpretador e, portanto, só pode
executar operações confiáveis.
Se o código falhar com um erro, ele interromperá a inicialização, e se propagará para a consulta de chamada, fazendo com que a transação ou subtransação corrente seja interrompida. Quaisquer ações já feitas em Perl não serão desfeitas; entretanto, este interpretador não será usado novamente. Se a linguagem for usada novamente, a inicialização será tentada novamente em um novo interpretador Perl.
Somente os superusuários podem alterar estas definições. Embora estas definições possam ser alteradas em uma sessão, elas não afetarão os interpretadores Perl que já foram usados para executar funções.
plperl.use_strict (boolean)
#
Quando definido como verdade, as compilações subsequentes de
funções escritas em PL/Perl terão o
pragma strict ativado.
Este parâmetro não afeta as funções já compiladas na sessão
corrente.
As funcionalidades a seguir estão ausentes no PL/Perl, mas seriam contribuições bem-vindas.
As funções PL/Perl não podem chamar umas às outras diretamente.
O SPI ainda não está totalmente implementado.
Se estiver sendo buscado conjuntos de dados muito grandes usando
spi_exec_query, deve-se estar ciente de que
todos estes dados vão para a memória.
Isto pode ser evitado isto usando
spi_query/spi_fetchrow,
conforme mostrado anteriormente.
Um problema semelhante ocorre se uma função retornando conjunto
passar um grande conjunto de linhas de volta para o
PostgreSQL via return.
Este problema também pode ser evitado usando
return_next para cada linha retornada,
conforme mostrado anteriormente.
Quando a sessão termina normalmente, e não devido a um erro fatal,
todos os blocos END que foram definidos
são executados.
No momento, nenhuma outra ação é executada.
Especificamente, os descritores de arquivo não são liberados
automaticamente, e os objetos não são destruídos automaticamente.