Estudo do Sistema de Gestão de Bases de Dados PostgreSQL. André Ricardo Carlos Nobre Cristiano Lopes Nº Nº Nº 17662

Transcrição

1 Estudo do Sistema de Gestão de Bases de Dados PostgreSQL André Ricardo Carlos Nobre Cristiano Lopes Nº Nº Nº 17662

2 Índice 1 Introdução Introdução histórica e aplicabilidade do sistema estudado Notas sobre a instalação do sistema 6 2 Cobertura do SQL DDL Data Definition Language CREATE DATABASE CREATE TABLE CONSTRAINTS CREATE INDEX CREATE VIEW CREATE TRIGGER CREATE FUNCTION ALTER DATABASE ALTER TABLE ALTER INDEX ALTER VIEW ALTER TRIGGER ALTER FUNCTION DROP DATABASE DROP TABLE DROP INDEX DROP VIEW DROP TRIGGER DROP FUNCTION DML Data Manipulation Language INSERT UPDATE DELETE TRUNCATE SELECT 29 3 Armazenamento e Estrutura de ficheiros Armazenamento Organização Tabela de sistema Sistema de ficheiros e gestão de buffer Organização do shared buffer Funcionamento do shared buffer Performance e tuning Estrutura de ficheiros 40

3 3.2.1 Representação interna dos ficheiros Tabela Free Space Map Visibility Map Tabela Toast Conclusão 42 4 Indexação e hashing Indexação B-Tree Hash GiST GIN Índices multi-coluna Ordenação de índices Combinação de vários índices Índices únicos Índices em expressões Índices parciais Classes e famílias de operadores Análise ao uso dos índices 55 5 Processamento e optimização de perguntas Ciclo de uma query no PostgreSQL Fase de ligação Fase de parsing Fase de rescrita Fase de planeamento e optimização Fase de execução Dicas de performance no PostgreSQL Conclusão 71 6 Gestão de transacções e controlo de concorrência Atomicidade, consistência, isolamento e durabilidade 72

4 6.2 Conclusão 78 7 Suporte para bases de dados distribuídas 79 8 Outras características do PostgreSQL Tipos de dados Linguagens procedimentais Extensibilidade do PostgreSQL XML e funções de suporte 92 9 Bibliografia 98

5 1 Introdução No seguimento do estudo efectuado ao longo da disciplina de Sistemas de Bases de Dados, acerca das metodologias utilizadas na implementação dos mesmos, surge o relatório seguinte, que visa consolidar e alargar conhecimentos, e principalmente efectuar uma confrontação entre as várias opções teóricas disponíveis e decisões de implementação tomadas na prática num sistema concreto. 1.1 Introdução histórica e aplicabilidade do sistema estudado Escolha do sistema a estudar Dada a liberdade quase total para a escolha do sistema a estudar foi necessário tomar uma decisão, tendo a nossa escolha recaído sobre o sistema PostgreSQL. A decisão foi tomada, depois de alguma pesquisa acerca dos sistemas mais utilizados actualmente, tendo pesado grandemente na decisão factores como a qualidade da documentação, a facilidade de acesso à mesma, a utilização do sistema para dar resposta a cenários de grande escala e o reconhecimento da existência do factor inovação na implementação do mesmo. O PostgreSQL pareceu-nos ser bastante competente em todos os critérios que definimos, sendo utilizado em sistemas de grande escala (e.g skype ver Link, imdb), bem documentado, com documentação disponível na web, e com algumas inovações/demarcações de alguns sistemas concorrentes. Breve introdução histórica O sistema PostgreSQL nasceu de um projecto académico da Universidade de Berkley (Califórnia) liderado pelo Professor Michael Stonebraker, com o objectivo de explorar conceitos objecto-relacionais em bases de dados. Na altura, entre 1986 e 1994 o sistema evoluiu ainda com a denominação de Postgres (curiosamente ainda utilizada hoje em dia por razões óbvias) no seio académico, tendo sido objecto de desenvolvimento activo por parte de alunos e professores com a introdução de características ainda presentes na versão actual, como regras, procedimentos índices de tipo extensível entre outros. Em 1995 e sob o comando de dois alunos, Andrew Yu e Jolly Chen, foi substituída a linguagem utilizada para efectuar queries, por uma outra que implementava a especificação SQL, tendo também o nome do sistema evoluído para Postgres95. Em 1996 é dado o grande salto por parte do Postgres95 com a adesão em massa de vários programadores provenientes do mundo open-source,que impulsionaram o desenvolvimento do sistema permitindo que nele surgissem funcionalidades que hoje lhe dão fama, como seja o modelo MVCC utilizado para garantir propriedades ACID, extensão das construções SQL, melhoramento da performance, para apenas mencionar algumas. Estávamos nesta altura na versão 6 do sistema, que continuou a evoluir graças ao esforço da comunidade open-source que com a chegada da versão 7 já incluía muitos melhoramentos como Write Ahead Log para implementar durabilidade e consistência de forma melhorada,tabelas TOAST para tuplos muito grandes, suporte para várias linguagens procedimentais entre tantas outras estudadas ao longo deste relatório. 5

6 Actualmente o sistema encontra-se na versão 8.4 tendo entrado definitivamente no mercado empresarial, e também no mundo Windows, mas mantendo-se open-source e com o mesmo espírito de inovação original com que foi criado na Universidade de Berkley. O mundo PostgreSQL O sítio de referência para o PostgreSQL é encontrado no endereço a partir do qual pode ser encontrada toda a documentação base do sistema e também uma wiki onde são apresentados diversos artigos sobre o mesmo. Estão também disponíveis várias mailing lists onde são discutidos vários assuntos relacionados com o PostgreSQL e onde qualquer pessoa pode obter resposta para as questões que tenha. O código fonte do sistema pode ser obtido a partir do sítio indicado acima e instaladores para rapidamente por o sistema a funcionar podem ser encontrados em Pode também ser interessante, no contexto de utilização do sistema num ambiente web, consultar que providência pacotes prontos a utilizar com o PostgreSQL, php e o servidor web apache. É ainda de potencial interesse o programa de administração pgadmin que pode ser encontrado em Notas sobre a instalação do sistema A instalação do sistema é bastante simples, pois estão disponíveis instaladores para todos os sistemas operativos mais utilizados (unix-based, windows).o sistema é licenciado através da licença BSD que basicamente permite que o sistema seja utilizado de forma gratuita, com permissão para modificar, copiar e distribuir sem qualquer tipo de problema, desde que a licença seja mantida. O código fonte está disponível e pode ser compilado seguindo os passos indicados no link. Alguma das opções de configuração aquando do momento da compilação são apresentadas no decurso do relatório, mas para uma utilização de teste recomenda-se a utilização dos instaladores que contêm os binários e uma configuração sólida de base. 6

7 2 Cobertura do SQL Neste capítulo vamos abordar a cobertura que o sistema de base de dados PostgreSQL faz do standard SQL. Vamos abordar em primeiro lugar a cobertura a nível de DDL Data Definition Language e depois a cobertura do DML Data Manipulation Language. 2.1 DDL Data Definition Language Neste capítulo vamos abordar o processo de criação das estruturas das bases de dados e também como é que o PostgreSQL cobre o standard SQL nesse capítulo em particular CREATE DATABASE CREATE DATABASE name [ [ WITH ] [ OWNER [=] dbowner ] [ TEMPLATE [=] template ] [ ENCODING [=] encoding ] [ LC_COLLATE [=] lc_collate ] [ LC_CTYPE [=] lc_ctype ] [ TABLESPACE [=] tablespace ] [ CONNECTION LIMIT [=] connlimit ] ] O comando CREATE DATABASE cria uma nova base dados no PostgreSQL. name representa o nome da base de dados que se vai criar, dbowner é o nome do utilizador que será dono da nova base de dados, dbowner também pode ser definido como DEFAULT, ou seja, o utilizador que executa o comando. Sempre que o comando CREATE DATABASE é chamado o sistema vai na realidade criar uma cópia duma base de dados já existente. É a partir deste template que as novas bases de dados serão criadas. Por defeito é feita uma copia duma base de dados padrão chamada template1. É ainda possível fazer modificações neste template1 que terão depois repercussões nas futuras bases de dados geradas a partir desse template. Para além do template1 existe outro padrão que pode ser usado, nomeadamente, o template0, este padrão é uma cópia exacta do template1 inicial, ou seja, contém apenas os objectos predefinidos pelo PostgreSQL para uma base de dados. O template0 por razões óbvias nunca deve ser alterado. O PostgreSQL permite ainda a criação de mais padrões caso sejam necessários. Com encoding é possível definir qual o tipo de codificação de caracteres que se pretende usar. No standard SQL não se encontra presente o comando CREATE DATABASE, a implementação deste é feita pelos sistemas de base de dados. 7

8 2.1.2 CREATE TABLE CREATE [ [ GLOBAL LOCAL ] { TEMPORARY TEMP } ] TABLE table_name ( [ { column_name data_type [ DEFAULT default_expr ] [ column_constraint [... ] ] table_constraint LIKE parent_table [ { INCLUDING EXCLUDING } { DEFAULTS CONSTRAINTS INDEXES } ]... } [,... ] ] ) [ INHERITS ( parent_table [,... ] ) ] [ WITH ( storage_parameter [= value] [,... ] ) WITH OIDS WITHOUT OIDS ] [ ON COMMIT { PRESERVE ROWS DELETE ROWS DROP } ] [ TABLESPACE tablespace ] onde column_constraint é: [ CONSTRAINT constraint_name ] { NOT NULL NULL UNIQUE index_parameters PRIMARY KEY index_parameters CHECK ( expression ) REFERENCES reftable [ ( refcolumn ) ] [ MATCH FULL MATCH PARTIAL MATCH SIMPLE ] [ ON DELETE action ] [ ON UPDATE action ] } [ DEFERRABLE NOT DEFERRABLE ] [ INITIALLY DEFERRED INITIALLY IMMEDIATE ] e table_constraint é: [ CONSTRAINT constraint_name ] { UNIQUE ( column_name [,... ] ) index_parameters PRIMARY KEY ( column_name [,... ] ) index_parameters CHECK ( expression ) FOREIGN KEY ( column_name [,... ] ) REFERENCES reftable [ ( refcolumn [,... ] ) ] [ MATCH FULL MATCH PARTIAL MATCH SIMPLE ] [ ON DELETE action ] [ ON UPDATE action ] } [ DEFERRABLE NOT DEFERRABLE ] [ INITIALLY DEFERRED INITIALLY IMMEDIATE ] index_parameters em UNIQUE e PRIMARY KEY são: [ WITH ( storage_parameter [= value] [,... ] ) ] [ USING INDEX TABLESPACE tablespace ] O comando CREATE TABLE cria uma uma nova tabela, com nome table_name, inicialmente vazia, na base de dados actual. TEMPORARY ou TEMP permitem indicar que a tabela que vai ser criada é temporária. As tabelas temporárias são automaticamente eliminadas no fim de uma sessão, ou opcionalmente no fim de cada transacção caso a cláusula ON COMMIT tenha sido especificada. A cláusula ON COMMIT serve precisamente para controlar o comportamento das tabelas temporárias no fim de uma transacção. Em caso de omissão o sistema considera por defeito que nenhuma acção é executada no fim de cada transacção e a tabela só é eliminada no fim da sessão, este comportamento pode ser indicado explicitamente incluindo o comando PRESERVE ROWS. Caso se queira apagar todas as linhas da tabela temporária, ou seja, esvaziar a tabela no fim de cada transacção, então deve-se incluir o comando DELETE ROWS, e por último, se for necessário apagar a tabela temporária no fim da transacção deve-se incluir o comando DROP. É necessário especificar quais são as colunas que a nova tabela vai ter. Isto é feito indicando uma lista de column_names, data_type e column_constraint com esta 8

9 última sempre opcional. column_name representa o nome da coluna que será criada na nova tabela e data_type representa o tipo de dados que essa coluna poderá armazenar. Sobre os tipos de dados suportados pelo sistema de base de dados PostgreSQL deve-se consultar o Capítulo 8. colum_constraint representa uma restrição aplicada a essa coluna. Trata-se de uma cláusula opcional que define um determinado número de condições que tanto as novas linhas, como as antigas ao serem actualizadas, devem respeitar. Uma restrição é um objecto SQL que ajuda a definir qual o conjunto de valores válidos para uma determinada tabela. Para além de column_constraint também é possível definir outro tipo de restrições, desta feita associadas não só a uma coluna em particular mas à tabela em geral, isto é feito mais concretamente com a cláusula opcional table_constraint. table_constraint, como já foi referido, não se encontra ligada a nenhuma coluna em particular, este tipo de restrição pode referir-se a qualquer conjunto de colunas presente na tabela. Como consequência deste facto todas as column_constraint podem ser escritas como table_constraint, aliás, column_constraint existe apenas para simplificar o processo de escrita de restrições que apenas se aplicam a uma coluna. A cobertura que o sistema de base de dados PostgreSQL faz das restrições será abordada adiante com mais detalhe. A cláusula opcional INHERITS permite especificar uma lista de tabelas, das quais a nova tabela irá herdar automaticamente todas as colunas. Isto cria uma relação persistente entre a tabela original e a nova tabela. Por sua vez, a cláusula LIKE, permite especificar uma tabela que servirá como padrão para aquela que se está a criar. A nova tabela vai copiar automaticamente de parent_table o nome das colunas, o tipo de dados de cada uma e caso existam as suas restrições. Ao contrário de INHERITS, a nova tabela e a parent_table não terão qualquer relação. As modificações feitas na coluna original não terão qualquer efeito na nova tabela. É ainda oferecida liberdade de definir algumas características que queremos ver na nova tabela. Através das palavras reservadas INCLUDING e EXCLUDING podemos definir se queremos incluir ou não, os valores por defeito de cada coluna com INCLUDING/EXCLUDING DEFAULTS, as restrições de cada coluna com INCLUDING/EXCLUDING CONSTRAINTS e por último, os índices da tabela original com INCLUDING/EXCLUDING INDEXES. WITH permite especificar parâmetros opcionais de armazenamento para uma tabela ou índice. O comando CREATE TABLE usado no sistema PostgreSQL cobre todo o standard SQL, com algumas excepções que é importante referir. Apesar da sintaxe de CREATE TEMPORARY TABLE ser semelhante à do standard, o efeito não é o mesmo. No standard, as tabelas temporárias são definidas apenas uma vez e existem, mesmo que inicialmente se encontrem vazias, em todas as sessões em que são necessárias. No PostgreSQL pelo contrário é necessário em cada sessão inserir o comando CREATE TEMPORARY TABLE por cada tabela temporária que se vá usar. Isto permite que diferentes sessões usem de forma diferente o mesmo nome da tabela temporária, enquanto que no standard a tabela temporária terá sempre a mesma estrutura em todas as sessões. A noção de CREATE TEMPORARY TABLE do standard SQL é ignorada por praticamente todos os sistemas de base de dados e neste caso o PostgreSQL não foge à regra. 9

10 A distinção feita pelo standard entre tabelas temporárias globais e locais não se encontra incluída no PostgreSQL visto que essa distinção está dependente do conceito de módulos, conceito esse que o PostgreSQL não inclui. De qualquer forma o PostgreSQL aceita as palavras reservadas GLOBAL e LOCAL na declaração de tabelas temporárias por razões de compatibilidade, mesmo não tendo qualquer efeito prático. A cláusula ON COMMIT para tabelas temporárias também é semelhante à presente no standard SQL mas com algumas diferenças. Se a cláusula ON COMMIT for omitida, o SQL define que o comportamento por defeito deve ser ON COMMIT DELETE ROWS, enquanto que no PostgreSQL é ON COMMIT PRESERVE ROWS. É também importante salientar que o comando ON COMMIT DROP é uma extensão do PostgreSQL. O standard SQL indica que as restrições de colunas do tipo CHECK só podem referir-se à coluna para a qual foram definidas e que apenas as restrições da tabela é que podem referir-se a várias colunas. O PostgreSQL não impõe estão restrição e trata as restrições de tabelas e colunas de forma semelhante. O conceito de múltiplas heranças através da cláusula INHERITS é uma extensão do PostgreSQL. O standard SQL define desde 1999 o conceito de herança mas com sintaxe e semântica diferente. Este conceito do standard não é suportado ainda pelo PostgreSQL. O PostgreSQL permite criar tabelas sem colunas, isto é uma extensão ao standard SQL, que não permite que tal aconteça. A cláusula WITH também é uma extensão do PostgreSQL. Não existem parâmetros de armazenamento no standard SQL. Para além da cláusula WITH, as cláusulas TABLESPACE e USING INDEX TABLESPACE também são extensões CONSTRAINTS Na grande maioria das situações, as restrições impostas pelas definições de tipo de dados são demasiado simples e limitadas para garantir aquilo que é desejado. Para contornar esta limitação o SQL permite definir restrições para colunas e tabelas. O sistema de base de dados PostgreSQL suporta vários tipos de restrições, nomeadamente, restrições CHECK, restrições NOT NULL, restrições UNIQUE, restrições de chave primária e restrições de chave estrangeira. As restrições do tipo CHECK são as mais genéricas de todas, permitem especificar que os valores duma determinada coluna têm de satisfazer uma determinada expressão booleana. CREATE TABLE example ( a integer, b integer, c integer, CHECK (a > 0), CHECK (c < b) ); 10

11 As restrições do tipo NOT NULL apenas permitem especificar que uma determinada coluna não pode armazenar valores nulos. Este tipo de restrição é sempre escrita como uma restrição duma coluna e nunca duma tabela. Uma restrição NOT NULL é equivalente a uma restrição do tipo CHECK (column_name IS NOT NULL), mas no PostgreSQL criar uma restrição do tipo NOT NULL acaba por ser mais eficiente. Para além das restrições do tipo NOT NULL também é possível definir uma restrição para uma coluna do tipo NULL, esta não obriga a que uma coluna seja nula mas sim que pode ou não ser nula. Este tipo restrições não se encontra no standard SQL, é uma extensão do PostgreSQL que foi adicionada meramente por questões de compatibilidade com outros sistemas de base de dados. CREATE TABLE example ( a integer NOT NULL, b integer, c integer NOT NULL ); As restrições do tipo UNIQUE garantem que a informação presente numa determinada coluna é única para todas as linhas, ou seja, garantem que para a dada coluna não existem valores iguais. A excepção a este caso trata-se dos casos em que existem valores nulos em mais do que uma linha da coluna, os valores nulos não são considerados como iguais nesta comparação. Este comportamento encontra-se de acordo com o standard SQL. CREATE TABLE example ( a integer UNIQUE ); CREATE TABLE example2 ( a integer, b integer, c integer, UNIQUE (a, c) ); As restrições de chaves primárias no fundo são uma combinação de outros dois tipos de restrições, nomeadamente, uma restrição do tipo NOT NULL e uma restrição do tipo UNIQUE. A restrição PRIMARY KEY é equivalente a UNIQUE NOT NULL. Uma PRIMARY KEY indica que uma coluna ou grupo de colunas pode ser usado como identificador único para linhas da tabela. No máximo uma tabela só pode ter uma PRIMARY KEY, podem existir várias UNIQUE NOT NULL mas só uma pode ser identificada como PRIMARY KEY. CREATE TABLE example ( a integer PRIMARY KEY ); CREATE TABLE example2 ( a integer, b integer, c integer, PRIMARY KEY (a, c) ); Restrições de chave estrangeira garantem que os valores numa coluna ou num grupo de 11

12 colunas têm de existir numa outra coluna de outra tabela. Este tipo de restrições é feito através da cláusula REFERENCES para restrições especificadas em colunas ou através de FOREIGN KEY (column_name) REFERENCES other_table (column_name) para restrições da tabela. De notar que nas restrições de tabela podem ser referenciados grupos de colunas: CREATE TABLE example ( a integer REFERENCES other_table (c1) ); CREATE TABLE example2 ( a integer PRIMARY KEY, b integer, c integer, FOREIGN KEY (b, c) REFERENCES other_table (c1, c2) ); CREATE INDEX CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] name ON table [ USING method ] ( { column ( expression ) } [ opclass ] [ ASC DESC ] [ NULLS { FIRST LAST } ] [,...] ) [ WITH ( storage_parameter = value [,... ] ) ] [ TABLESPACE tablespace ] [ WHERE predicate ] CREATE INDEX permite criar um índice com nome name na tabela table. Um índice é um instrumento usado principalmente para melhorar a performance de uma base de dados, é importante também mencionar que um uso incorrecto pode por outro lado levar a um decréscimo na performance). Para especificar o INDEX é necessário indicar nomes de colunas, column, da tabela, table, ou então expressões baseadas numa ou mais colunas da tabela, normalmente escritas dentro de parêntesis, expression. UNIQUE garante que o sistema verifica a existência de valores duplicados na tabela quando o INDEX é criado e sempre que for inserida informação. Todas as tentativas de inserir informação já existente resultam em erro. CONCURRENTLY garante o PostgreSQL não bloqueia quaisquer operações de INSERT, UPDATE ou DELETE durante a criação do INDEX. Sem esta opção o sistema bloqueia todas as operações de escrita durante a criação do INDEX. As operações de leitura são sempre permitidas, com ou sem CONCURRENTLY. USING method permite especificar o método de indexação que deve ser usado pelo sistema de base de dados. O PostgreSQL disponibiliza os seguintes métodos: B-tree, hash, GiST e GIN. Para além destes métodos o PostgreSQL permite também que o utilizador defina os seus próprios métodos. ASC e DESC designam os ordens de ordenação disponíveis, ASC para ascendente e DESC 12

13 para descendente. ASC é o comportamento assumido por defeito pelo sistema. NULLS FIRST e NULLS LAST especificam a ordem em que os valores nulos surgem. NULLS FIRST especifica que os valores nulos aparecem em primeiro lugar, este é o comportamento assumido pelo sistema quando DESC é especificado. NULLS LAST especifica que os valores nulos aparecem depois dos valores não nulos, este é o comportamento assumido pelo sistema quando DESC não é especificado. Quando a cláusula WHERE é especificada é criado um INDEX parcial. Um INDEX parcial é um INDEX que contém apenas entradas para um subconjunto da tabela, normalmente um subconjunto que seja mais útil para indexação que toda a tabela. A expressão predicate que é usada em WHERE permite especificar o subconjunto desejado. Em predicate podemos referenciar várias colunas da tabela e não só aquelas que vão ser alvo de indexação. CREATE UNIQUE INDEX table_index ON table (a); CREATE INDEX é uma extensão do PostgreSQL. O standard SQL não disponibiliza índices CREATE VIEW CREATE [ OR REPLACE ] [ TEMP TEMPORARY ] VIEW name [ ( column_name [,...] ) ] AS query O comando CREATE VIEW permite criar uma nova VIEW de uma dada query. name representa o nome da nova VIEW e query pode tanto ser uma operação de SELECT como uma operação VALUES. A VIEW não cria qualquer tipo de dados em disco, simplesmente executa a query sempre que a VIEW é usada. CREATE OR REPLACE garante que caso uma VIEW com o mesmo nome já exista, esta vai ser substituída pela nova. É possível definir, apesar de ser opcional, uma lista de nomes, column_name, a serem usadas pelas colunas da VIEW, caso nenhuma lista seja definida o sistema deduz os nomes a partir da query. O PostgreSQL permite a criação de views temporárias com o comando TEMPORARY ou TEMP. Estas views são automaticamente eliminadas do sistema no fim de cada sessão. Caso alguma das tabelas referenciadas pela VIEW for temporária então esta também será automaticamente temporária, mesmo sem a inclusão do comando TEMPORARY ou TEMP. O standard SQL contém algumas funcionalidades adicionais para o comando CREATE VIEW. Por enquanto o PostgreSQL não permite operações de INSERT, UPDATE e DELETE numa VIEW. CREATE OR REPLACE VIEW é uma extensão do PostgreSQL, assim como é o conceito de VIEW temporária. 13

14 2.1.6 CREATE TRIGGER CREATE TRIGGER name { BEFORE AFTER } { event [ OR... ] } ON table [ FOR [ EACH ] { ROW STATEMENT } ] EXECUTE PROCEDURE funcname ( arguments ) CREATE TRIGGER cria um novo TRIGGER com nome name que fica associado à tabela table e que executa uma função funcname quando um evento event ocorre. É possível definir se o TRIGGER é disparado antes ou depois de event, isto é feito recorrendo aos comandos BEFORE e AFTER. funcname, como já foi referido, representa a função que será chamada, a esta função pode ainda ser passada uma lista de argumentos, arguments. Este tema será amplamente discutido mais adiante. event pode ser um dos seguintes tipos de operações: INSERT, UPDATE, DELETE ou TRUNCATE. É ainda possível definir definir vários eventos usando OR. É possível definir quantas vezes o TRIGGER é disparado, com FOR EACH ROW presente, o sistema vai disparar o TRIGGER uma vez por cada linha que seja afectada por event, com FOR EACH STATEMENT apenas é disparado uma vez por cada operação. Caso nenhum for especificado o sistema considera FOR EACH STATEMENT como sendo o comportamento por defeito. Para o caso de operações de TRUNCATE deve-se, ou não definir nenhuma das duas opções e assim deixar o sistema usar o comportamento por defeito, ou então definir FOR EACH STATEMENT explicitamente. Para a operação de TRUNCATE não pode ser usado o comando FOR EACH ROW. Isto deve-se ao facto de TRUNCATE afectar todas as linhas da tabela, assim seria extremamente ineficiente disparar o TRIGGER uma vez por cada linha existente na tabela. Se vários TRIGGER do mesmo tipo forem definidos para a mesma tabela e responderem ao mesmo evento, então eles serão disparados por ordem alfabética. Para criar TRIGGERS numa determinada table o utilizador tem de ter privilégios para tal. O comando CREATE TRIGGER na base de dados PostgreSQL implementa um subconjunto das funcionalidades que o standard SQL oferece. As seguintes funcionalidade encontram-se ausentes do PostgreSQL: Permitir que os TRIGGER sejam disparados quando determinadas colunas são actualizadas. O standard SQL permite referir-se ao estado de uma linha antes duma operação e depois duma operação, isto é feito recorrendo às palavras chave old e new, como o PostgreSQL permite que os procedimentos dos TRIGGER sejam definidos num sem número de linguagens, os acessos à informação são feitos de formas diferentes consoante a linguagem usada. O PostgreSQL apenas permite que sejam chamadas funções criadas pelo utilizador quando o TRIGGER é disparado, o standard permite chamar um sem número de comandos SQL, como por exemplo CREATE TABLE. Este aspecto é facilmente contornável, basta o utilizador definir uma função que chame o comando SQL desejado. Como já foi referido anteriormente o PostgreSQL despoleta os TRIGGER por ordem alfabética, por sua vez o standard define que devem ser despoletados por ordem de criação. A capacidade de especificar várias acções para um só TRIGGER e a possibilidade de 14

15 definir TRIGGERS para a operação TRUNCATE são extensões do PostgreSQL CREATE FUNCTION CREATE [ OR REPLACE ] FUNCTION name ( [ [ argmode ] [ argname ] argtype [ { DEFAULT = } defexpr ] [,...] ] ) [ RETURNS rettype RETURNS TABLE ( colname coltype [,...] ) ] { LANGUAGE langname WINDOW IMMUTABLE STABLE VOLATILE CALLED ON NULL INPUT RETURNS NULL ON NULL INPUT STRICT [ EXTERNAL ] SECURITY INVOKER [ EXTERNAL ] SECURITY DEFINER COST execution_cost ROWS result_rows SET configuration_parameter { TO value = value FROM CURRENT } AS 'definition' AS 'obj_file', 'link_symbol' }... [ WITH ( attribute [,...] ) ] CREATE FUNCTION cria uma nova função, CREATE OR REPLACE FUNCTION cria uma nova função ou substitui uma já existente. É possível existirem várias funções com o mesmo nome desde que os seus argumentos sejam diferentes. A função é definida através do seu nome, representado por name, e por uma lista de argumentos. Cada argumento incluído nesta lista pode ser definido pelas cláusulas opcionais argmode e argname e pela cláusula obrigatória argtype. argmode representa o modo do argumento, por defeito é IN mas pode-se ser definido das seguintes formas: IN, OUT, INOUT e VARIADIC. argname é o nome do argumento. argtype é o tipo de dados do argumento da função. O retorno da função é definido com a cláusula RETURNS rettype ou com RETURNS TABLE ( colname coltype [,...] ) ]. Quando existem argumentos com modo OUT ou INOUT a cláusula RETURNS pode ser omitida. rettype é o tipo de dados do valor que será devolvido. Com RETURNS TABLE é possível definir uma tabela como retorno da função, esta tabela é definida através de uma lista de colunas, com cada coluna definida por colname, o nome da coluna, e coltype, o tipo de dados da coluna. O PostgreSQL permite a definição de funções num sem número de linguagens diferentes, alguns exemplos são: SQL, C, internal (funções escritas em C que foram estaticamente ligadas ao servidor PostgreSQL) ou até numa linguagem procedimental criada pelo utilizador. Para tal é necessário indicar qual a linguagem usada. Isto é feito com a cláusula langname. WINDOW indica que uma função é uma window function em vez de uma simples função. Isto é só útil para funções escritas em C. As cláusulas IMMUTABLE, STABLE e VOLATILE servem para informar o processador de 15

16 querys acerca do comportamento da função. Apenas uma das cláusulas pode ser especificada, também é possível ignorar esta questão e não incluir nenhuma das cláusulas. Neste caso o comportamento por defeito do sistema é assumir VOLATILE. IMMUTABLE indica que uma função não pode modificar a base de dados e que devolve sempre o mesmo resultado se lhe forem passados os mesmos argumentos, ou seja, é uma função que não usa qualquer informação presente na base de dados e não usa qualquer informação que não esteja presente na sua lista de argumentos. STABLE indica que a função não pode modificar a base de dados e que durante um varrimento duma tabela irá sempre devolver os mesmos resultados para os mesmos argumentos dados. VOLATILE indica que o valor da função pode mudar até mesmo durante o varrimento duma tabela, desta forma nenhuma optimização pode ser feita. Este como já foi referido é o comportamento por defeito. CALLED ON NULL INPUT, que é o comportamento por defeito em caso de omissão, indica que uma função deve ser chamada normalmente mesmo quando algum dos argumentos é nulo. RETURNS NULL ON NULL INPUT ou STRICT indica que a função irá devolver sempre um valor nulo quando um dos seus argumentos for nulo, o que acontece na realidade é que ao verificar que um dos argumentos é nulo, é logo devolvido nulo como resultado, nenhuma operação é processada. COST execution_cost é um número positivo que representa o valor estimado do custo de execução da função. Caso seja devolvida uma colecção de resultados então é assumido que execution_cost representa o custo por cada entrada na colecção. Caso nenhum execution_cost seja definido o sistema assume por defeito 1 unidade para funções em C e 100 unidades para funções noutras linguagens. ROWS result_rows é um número positivo que representa o número estimado de linhas que o plano de execução deve esperar para o resultado da função. Isto só é permitido quando a função é declarada para retornar uma colecção. Em caso de omissão é assumido um valor igual a O comando CREATE FUNCTION encontra-se definido no standard SQL desde A versão implementada pelo PostgreSQL é similar mas não totalmente compatível. O standard, por exemplo, não permite definir funções em várias linguagens diferentes. Por questões de compatibilidade com outros sistemas de base de dados, argmode pode surgir antes ou depois do argname, mas apenas a primeira é que se encontra de acordo com o standard SQL. 16

17 2.1.8 ALTER DATABASE ALTER DATABASE name [ [ WITH ] option [... ] ] onde option pode ser: CONNECTION LIMIT connlimit ALTER DATABASE name RENAME TO newname ALTER DATABASE name OWNER TO new_owner ALTER DATABASE name SET TABLESPACE new_tablespace ALTER DATABASE name SET configuration_parameter { TO = } { value DEFAULT } ALTER DATABASE name SET configuration_parameter FROM CURRENT ALTER DATABASE name RESET configuration_parameter ALTER DATABASE name RESET ALL ALTER DATABASE permite modificar os atributos duma base de dados. De entre as várias modificações que o comando ALTER permite fazer a uma base de dados, as mais importantes são: Com RENAME TO newname é possível modificar o nome da base de dados, através de OWNER TO new_owner pode-se definir outro utilizador como responsável pela base de dados, é possível ainda limitar o número de conexões concorrentes à base de dados com CONNECTION LIMIT connlimit. Com RESET ALL é possível reiniciar todas as características da base de dados. O comando ALTER DATABASE é uma extensão do sistema de base de dados PostgreSQL. 17

18 2.1.9 ALTER TABLE ALTER TABLE [ ONLY ] name [ * ] action [,... ] ALTER TABLE [ ONLY ] name [ * ] RENAME [ COLUMN ] column TO new_column ALTER TABLE name RENAME TO new_name ALTER TABLE name SET SCHEMA new_schema onde action pode ser um de: ADD [ COLUMN ] column type [ column_constraint [... ] ] DROP [ COLUMN ] column [ RESTRICT CASCADE ] ALTER [ COLUMN ] column [ SET DATA ] TYPE type [ USING expression ] ALTER [ COLUMN ] column SET DEFAULT expression ALTER [ COLUMN ] column DROP DEFAULT ALTER [ COLUMN ] column { SET DROP } NOT NULL ALTER [ COLUMN ] column SET STATISTICS integer ALTER [ COLUMN ] column SET STORAGE { PLAIN EXTERNAL EXTENDED MAIN } ADD table_constraint DROP CONSTRAINT constraint_name [ RESTRICT CASCADE ] DISABLE TRIGGER [ trigger_name ALL USER ] ENABLE TRIGGER [ trigger_name ALL USER ] ENABLE REPLICA TRIGGER trigger_name ENABLE ALWAYS TRIGGER trigger_name DISABLE RULE rewrite_rule_name ENABLE RULE rewrite_rule_name ENABLE REPLICA RULE rewrite_rule_name ENABLE ALWAYS RULE rewrite_rule_name CLUSTER ON index_name SET WITHOUT CLUSTER SET WITH OIDS SET WITHOUT OIDS SET ( storage_parameter = value [,... ] ) RESET ( storage_parameter [,... ] ) INHERIT parent_table NO INHERIT parent_table OWNER TO new_owner SET TABLESPACE new_tablespace ALTER TABLE permite modificar a definição de uma tabela criada anteriormente. De entre as modificações que o comando ALTER permite efectuar numa tabela anteriormente criada, as mais relevantes são: Com RENAME TO new_name é possível modificar o nome da tabela de name para new_name, é possível renomear as colunas da tabela com RENAME [ COLUMN ] column TO new_column. Com ALTER TABLE tanto se pode adicionar novas colunas à tabela como se pode eliminar colunas já existentes, isto é feito com ADD COLUMN e DROP COLUMN respectivamente. Pode-se alterar o tipo de dados das colunas com SET DATA TYPE, alterar ou remover os valores por defeito das colunas com SET/DROP DEFAULT e alterar se uma coluna aceita valores nulos ou não com SET/DROP NOT NULL. Permite adicionar uma restrição à tabela com ADD table_constraint, ou eliminar uma restrição já existente com DROP CONSTRAINT. Com DISABLE/ENABLE [ REPLICA ALWAYS ] TRIGGER permite configurar o despoletar ou não de triggers pertencentes à tabela. Mais à frente os triggers serão abordados com mais profundidade. Permite ainda definir as relações de herança entre tabelas com a cláusula INHERIT 18

19 parent_table ou eliminar relações já existentes com NO INHERIT parent_table. É ainda possível alterar o nome do utilizador que é considerado como sendo o dono da tabela com a cláusula OWNER TO new_owner, em que new_owner é o nome do novo dono. Os comandos ADD, DROP, SET DEFAULT e SET DATA TYPE (sem USING) encontram-se de acordo com o standard SQL. As outras formas são extensões do sistema de base de dados PostgreSQL. A capacidade de definir mais de uma alteração no mesmo comando ALTER TABLE também é uma extensão do sistema estudado. ALTER TABLE DROP COLUMN pode ser usado para eliminar a única coluna de uma tabela, deixando-a sem colunas. Isto, como já foi anteriormente referido, trata-se de uma extensão ao standard por parte do PostgreSQL, no standard isto não é aconselhado ALTER INDEX ALTER INDEX name RENAME TO new_name ALTER INDEX name SET TABLESPACE tablespace_name ALTER INDEX name SET ( storage_parameter = value [,... ] ) ALTER INDEX name RESET ( storage_parameter [,... ] ) ALTER INDEX permite modificar a definição de um INDEX criado anteriormente. Este comando é bastante limitado, permite renomear o INDEX, alterar o TABLESPACE, os parâmetros de armazenamento e pouco mais. Todas estas operações podem ser feitas também com o comando ALTER TABLE. ALTER INDEX é uma extensão do sistema de base de dados PostgreSQL ALTER VIEW ALTER VIEW name ALTER [ COLUMN ] column SET DEFAULT expression ALTER VIEW name ALTER [ COLUMN ] column DROP DEFAULT ALTER VIEW name OWNER TO new_owner ALTER VIEW name RENAME TO new_name ALTER VIEW name SET SCHEMA new_schema ALTER VIEW permite modificar a definição de uma VIEW criada anteriormente. O comando RENAME TO new_name permite renomear a VIEW, o comando OWNER TO new_owner permite alterar o dono da VIEW, é ainda possível definir ou eliminar os valores padrão para uma coluna através do comando SET/DROP DEFAULT. ALTER VIEW é uma extensão do sistema de base de dados PostgreSQL ao standard SQL. 19

20 ALTER TRIGGER ALTER TRIGGER name ON table RENAME TO newname ALTER TRIGGER permite modificar a definição de um TRIGGER criado anteriormente para a tabela table. Com a cláusula RENAME é possível renomear o TRIGGER de name para newname. Trata-se na realidade de um comando bastante limitado, só permitindo mesmo a modificação do seu nome. Caso seja necessário activar ou desactivar o TRIGGER em questão deve-se recorrer ao comando ALTER TABLE, como já foi mencionado antes. ALTER TRIGGER é uma extensão do PostgreSQL ao standard SQL ALTER FUNCTION ALTER FUNCTION name ( [ [ argmode ] [ argname ] argtype [,...] ] ) action [... ] [ RESTRICT ] ALTER FUNCTION name ( [ [ argmode ] [ argname ] argtype [,...] ] ) RENAME TO new_name ALTER FUNCTION name ( [ [ argmode ] [ argname ] argtype [,...] ] ) OWNER TO new_owner ALTER FUNCTION name ( [ [ argmode ] [ argname ] argtype [,...] ] ) SET SCHEMA new_schema onde action é um de: CALLED ON NULL INPUT RETURNS NULL ON NULL INPUT STRICT IMMUTABLE STABLE VOLATILE [ EXTERNAL ] SECURITY INVOKER [ EXTERNAL ] SECURITY DEFINER COST execution_cost ROWS result_rows SET configuration_parameter { TO = } { value DEFAULT } SET configuration_parameter FROM CURRENT RESET configuration_parameter RESET ALL ALTER FUNCTION permite modificar a definição de uma função criada anteriormente. É possível renomear a função com RENAME TO new_name, com OWNER TO new_owner pode-se alterar o dono da função e para além destas opções bastante simples pode-se ainda através da definição de uma action alterar um leque vasto de opções da função. Com action é possível definir que tipo de tratamento é dado à função quando é chamada com argumentos nulos, se CALLED ON NULL INPUT, se RETURNS NULL ON NULL INPUT ou STRICT. É possível redefinir IMMUTABLE, STABLE e VOLATILE. O significado destes diferentes modos foi amplamente discutido no CREATE FUNCTION. É ainda possível modicar os valores estimados de execution_cost e result_rows para qualquer valor que se deseje. O comando ALTER FUNCTION encontra-se parcialmente compatível com o presente no standard SQL. Por exemplo o standard permite que mais propriedades de uma função sejam modificadas mas não permite renomear uma função ou alterar o seu dono. 20