Silfar, "
Stored procedures são funções ou procedimentos que ficam guardados dentro do servidor de banco de dados e que ficam responsáveis pela aplicação de algoritmos, seja na transformação de um dado para geração de informação, na validação de entrada de dados ou até mesmo para execução de processos que de outra forma ficariam à cargo de outro ambiente de aplicação, em outra linguagem de programação. Para se escrever uma sp em qualquer linguagem suportada pelo PostgreSQL devemos primeiro instalar a linguagem no servidor. Este procedimento pode ser realizado através da aplicação createlang que acompanha o servidor ou através da instrução "create language plpgsql;". Um linguagem instalada pode ser do tipo trusted(cuja reflexo das ações fica restrito ao domínio do servidor SGDB) e untrusted(situação em que a linguagem consegue interagir com outros serviços além do SGDB como e-mail e também o filesystem). Escrevendo a primeira Stored Procedure: 1. *create function helloworld() returns varchar as *2.* $$ *3.* begin *4.* return 'Hello World!'; *5.* end *6.* $$ language 'plpgsql'; * A primeira linha temos a instrução que indica que esta é uma função chamada *helloworld* que retorna uma única informação do tipo *varchar*. A ultima palavra da primeira linha é "*as*" e indica o início do conteúdo da sp. Na linha 2 temos o delimitador de conteúdo *$$*, Ele deve ser usado para "conter" todas as instruções da sp. O uso desse limitador facilita a escrita do conteúdo da função em muito. *Antigamente era utilizada a aspa simples* e devido a isso toda vez que se tinha uma aspa simples dentro do código ela acabava sendo duplicada. Eram tempos mais difíceis onde com certeza se você não tivesse familiaridade com as aspas, voce não conseguia escrever uma função dinâmica. O *begin* inicia as instruções da sp. Quando todos nós que estamos acostumados com SQL vemos uma instrução begin, automaticamente pensamos em uma transação, porém, neste caso essa instrução indica somente o início de um bloco de código. Muitas pessoas esclarecem que uma stored procedure não consegue trabalhar com transações encadeadas dizendo que ela tem somente uma transação, ou melhor, que ela é uma única transação e isto esta correto. Esse fato ocorre por que para facilitar a gerência de recursos e destinados internamente à sp como estruturas de controle de processo, estado da execução das sql e outros ele foi restrito a somente *uma transação* e também por que esse modelo de implementação melhora a performance da execução de uma stored procedure. Se olharmos o código da implementação da plpgsql, por exemplo em *pl_exec.c*(41) veremos que o autor informa que através desse modelo ele consegue preparar as instruções e mante-las preparadas para caso de repetição de seu uso, aumentando assim a performance. Esse é um dos motivos. Mais para a frente veremos como trabalhar com sp's de forma que ela possam ter controle dos processos e "simular" transações. O *return* devolve o valor para a função, encerrando o processo. A instrução *end* da linha 5 finaliza o bloco de código da função e na linha 6 temos a instrução que informa para o postgreSQL qual *parser* deve ser utilizado para rodar a função. Isso implica também que se a linguagem tiver um *validator* o conteúdo da função sera verificado no momento de sua gravação. Antigamente só tinhamos essa operação no momento em que executávamos a sp. " -- Valter Cezar Prado Junior Analista TI Sem saber como fazer ele fez!
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
