9.13. Funções diversas

A Tabela 9-37 mostra diversas funções que retornam informações da sessão e do sistema.

A função session_user normalmente retorna o usuário que iniciou a conexão com o banco de dados corrente; imutável durante o período da conexão. A função current_user retorna o identificador do usuário utilizado na verificação de permissão. Normalmente é igual ao usuário da sessão, mas muda durante a execução das funções com o atributo SECURITY DEFINER. Na terminologia Unix o usuário da sessão é o "usuário real", enquanto o usuário corrente é o "usuário efetivo".

A função current_schema retorna o nome do esquema que está à frente do caminho de procura (ou o valor nulo, se o caminho de procura estiver vazio). Este é o esquema utilizado na criação de qualquer tabela, ou outro objeto nomeado, sem especificar o esquema a ser utilizado. A função current_schemas(boolean) retorna uma matriz contendo os nomes de todos os esquemas presentes no caminho de procura. A opção booleana determina se os esquemas do sistema incluídos implicitamente, tal como pg_catalog, serão incluídos no caminho de procura retornado.

A função version() retorna uma cadeia de caracteres descrevendo a versão do servidor PostgreSQL.

A Tabela 9-38 mostra as funções disponíveis para consultar e modificar os parâmetros de configuração em tempo de execução.

A função current_setting retorna o valor corrente da definição nome_da_definição. Corresponde ao comando SQL SHOW. Por exemplo:

=> SELECT current_setting('datestyle');

 current_setting
-----------------
 ISO, DMY
(1 linha)

A função set_config define o parâmetro nome_da_configuração como novo_valor. Se o parâmetro é_local for true, então o novo valor se aplica somente à transação corrente. Se for desejado que o novo valor seja aplicado à sessão corrente, deve ser utilizado false. Esta função corresponde ao comando SQL SET. Por exemplo:

=> SELECT set_config('log_statement_stats', 'off', false);

 set_config
------------
 off
(1 linha)

A Tabela 9-39 lista as funções que permitem o usuário consultar os privilégios de acesso aos objetos por meio de programa. Veja a Seção 5.7 para obter mais informações sobre privilégios.

A função has_table_privilege verifica se o usuário pode acessar a tabela de uma determinada forma. O usuário pode ser especificado pelo nome ou pelo ID (pg_user.usesysid) ou, se o argumento for omitido, será utilizado o current_user. A tabela pode ser especificada pelo nome ou pelo OID (Portanto, existem na verdade seis variantes de has_table_privilege, as quais podem ser distinguidas pelo número e tipos de seus argumentos). Quando especificado pelo nome, este pode ser qualificado pelo esquema, se for necessário. O tipo de privilégio de acesso desejado é especificado no texto da cadeia de caracteres, que deve ser avaliado como um dos seguintes valores: SELECT, INSERT, UPDATE, DELETE, RULE, REFERENCES ou TRIGGER (Entretanto, maiúsculas e minúsculas não fazem diferença). Um exemplo é:

SELECT has_table_privilege('meu_esquema.minha_tabela', 'select');

A função has_database_privilege verifica se o usuário pode acessar o banco de dados de uma determinada forma. As possibilidades para seus argumentos são análogas às da função has_table_privilege. Os tipos de acesso desejados devem ser avaliados como CREATE, TEMPORARY ou TEMP (que equivale a TEMPORARY).

A função has_function_privilege verifica se o usuário pode acessar a função de uma determinada forma. As possibilidades para seus argumentos são análogas às da função has_table_privilege. Ao especificar a função por meio de um texto em vez de seu OID, a entrada permitida é a mesma que para o tipo de dado regprocedure. O tipo de privilégio de acesso desejado deve atualmente ser avaliado como EXECUTE.

A função has_language_privilege verifica se o usuário pode acessar a linguagem procedural de um determinado modo. As possibilidades para seus argumentos são análogas às da função has_table_privilege. O tipo de privilégio de acesso desejado deve atualmente ser avaliado como USAGE.

A função has_schema_privilege verifica se o usuário pode acessar o esquema de uma determinada forma. As possibilidades para seus argumentos são análogas às da função has_table_privilege. O tipo de privilégio de acesso desejado deve atualmente ser avaliado como CREATE ou USAGE.

Para verificar se o usuário possui a opção de concessão do privilégio, deve ser anexado WITH GRANT OPTION à palavra chave do privilégio; por exemplo, 'UPDATE WITH GRANT OPTION'.

A Tabela 9-40 mostra as funções que verificam se um determinado objeto está visível no caminho de procura de esquema corrente. Uma tabela é dita visível se o esquema que a contém está no caminho de procura, e nenhuma tabela com o mesmo nome aparece antes no caminho de procura. Equivale a declarar que a tabela pode ser referenciada pelo nome sem uma qualificação explícita do esquema. Por exemplo, para listar o nome de todas as tabelas visíveis:

SELECT relname FROM pg_class WHERE pg_table_is_visible(oid);

A função pg_table_is_visible realiza a verificação para as tabelas (ou visões, ou qualquer outro tipo de entrada em pg_class). As funções pg_type_is_visible, pg_function_is_visible, pg_operator_is_visible, pg_opclass_is_visible e pg_conversion_is_visible realizam o mesmo tipo de verificação de visibilidade para os tipos (e domínios), funções, operadores, classes de operadores e conversões, respectivamente. Para as funções e os operadores, um objeto no caminho de procura é visível se não existir nenhum objeto com o mesmo nome e mesmos tipos de dado dos argumentos aparecendo antes no caminho. Para as classes de operadores, são considerados tanto o nome quanto o método de acesso de índice associado.

Todas estas funções requerem OIDs de objeto para identificar o objeto a ser verificado. Se for desejado verificar um objeto pelo seu nome, é conveniente utilizar os tipos aliás de OID (regclass, regtype, regprocedure ou regoperator). Exemplo:

SELECT pg_type_is_visible('meu_esquema.widget'::regtype);

Deve ser observado que não faz muito sentido testar um nome não qualificado desta maneira — se o nome puder ser reconhecido, então tem que ser visível.

A Tabela 9-41 mostra as funções que extraem informações dos catálogos do sistema. As funções pg_get_viewdef, pg_get_ruledef, pg_get_indexdef, pg_get_triggerdef e pg_get_constraintdef reconstroem, respectivamente, os comandos de criação da visão, regra, índice, gatilho e restrição; deve ser observado que esta é uma reconstrução por descompilação, e não o texto do comando original. A maioria destas funções estão presentes em duas formas, uma das quais pode, opcionalmente, gerar o resultado de forma "alinhada" (pretty-print). O formato alinhado é mais legível, mas o formato padrão tem mais probabilidade de ser interpretado da mesma maneira nas versões futuras do PostgreSQL; deve ser evitada a utilização do formato alinhado com a finalidade de geração de dumps. Passar false para o parâmetro de impressão alinhada produz o mesmo resultado da variante que não possui o parâmetro. A função pg_get_expr descompila a forma interna de uma determinada expressão, tal como o valor padrão para a coluna. Pode ser útil ao se examinar o conteúdo dos catálogos do sistema. A função pg_get_userbyid extrai o nome do usuário a partir do número de identificação do usuário.

As funções mostradas na Tabela 9-42 retornam os comentários previamente armazenados por meio do comando COMMENT. Se nenhum comentário correspondendo aos parâmetros especificados puder ser encontrado, o valor nulo é retornado.

A forma da função obj_description() com dois parâmetros retorna o comentário para o objeto do banco de dados especificado pelo seu OID e pelo nome do catálogo do sistema que o contém. Por exemplo, obj_description(123456,'pg_class') retorna o comentário para a tabela com OID 123456. A forma de obj_description() com um parâmetro requer apenas o OID do objeto. Está obsoleta, porque não existe garantia dos OIDs serem únicos entre diferentes catálogos do sistema; portanto, pode ser retornado um comentário errado.

A função col_description() retorna o comentário para a coluna da tabela especificada pelo OID da tabela, e pelo número da coluna. A função obj_description() não pode ser utilizada para colunas de tabela, porque as colunas não possuem OIDs próprios.

=> SELECT current_database();

 current_database
------------------
 template1
(1 linha)

=> SELECT current_schema();

 current_schema
----------------
 public
(1 linha)

=> SELECT CURRENT_USER AS usuario;

 usuario
----------
 postgres
(1 linha)

=> SELECT SESSION_USER as usuario;

 usuario
----------
 postgres
(1 linha)

=> SELECT USER as usuario;

 usuario
----------
 postgres
(1 linha)

=> SELECT current_setting('client_encoding');

 current_setting
-----------------
 LATIN1
(1 linha)

=> SELECT current_setting('server_encoding');

 current_setting
-----------------
 LATIN1
(1 linha)

=> SELECT current_setting('server_version');

 current_setting
-----------------
 7.4.1
(1 linha)

=> SELECT current_setting('transaction_isolation');

 current_setting
-----------------
 read committed
(1 linha)

=> SELECT version() AS versao;

                       versao
------------------------------------------------------------
 PostgreSQL 7.4.7 on i386-redhat-linux-gnu,\
 compiled by GCC i386-redhat-linux-gcc (GCC) 3.4.2 20041017\
 (Red Hat 3.4.2-6.fc3)
(1 linha)

SELECT db_name() AS current_database

current_database
----------------
pubs
(1 row(s) affected)

SELECT CURRENT_USER AS usuario;

usuario
-------
dbo
(1 row(s) affected)

SELECT SESSION_USER as usuario

usuario
-------
dbo
(1 row(s) affected)

SELECT SYSTEM_USER as usuario

usuario
-------
sa
(1 row(s) affected)

SELECT @@VERSION AS versao

versao
-----------------------------------------------------------
Microsoft SQL Server  2000 - 8.00.760 (Intel X86)
        Dec 17 2002 14:22:05
        Copyright (c) 1988-2003 Microsoft Corporation
        Enterprise Edition on Windows NT 5.2 (Build 3790: )
(1 row(s) affected)

SQL> SELECT sys_context ('USERENV', 'CURRENT_SCHEMA') FROM sys.dual;

SYS_CONTEXT('USERENV','CURRENT_SCHEMA')
---------------------------------------
SCOTT

SQL> SELECT sys_context ('USERENV', 'CURRENT_USER') FROM sys.dual;

SYS_CONTEXT('USERENV','CURRENT_USER')
-------------------------------------
SCOTT

SQL> SELECT sys_context ('USERENV', 'DB_NAME') FROM sys.dual;

SYS_CONTEXT('USERENV','DB_NAME')
--------------------------------
orcl

SQL> SELECT sys_context ('USERENV', 'HOST') FROM sys.dual;

SYS_CONTEXT('USERENV','HOST')
-----------------------------
CASA\HALLEY

SQL> SELECT sys_context ('USERENV', 'IP_ADDRESS') FROM sys.dual;

SYS_CONTEXT('USERENV','IP_ADDRESS')
-----------------------------------
200.165.203.130

SQL> SELECT sys_context ('USERENV', 'LANGUAGE') FROM sys.dual;

SYS_CONTEXT('USERENV','LANGUAGE')
---------------------------------
AMERICAN_AMERICA.WE8ISO8859P1

SQL> SELECT sys_context ('USERENV', 'NETWORK_PROTOCOL') FROM sys.dual;

SYS_CONTEXT('USERENV','NETWORK_PROTOCOL')
-----------------------------------------
tcp

SQL> SELECT sys_context ('USERENV', 'NLS_DATE_FORMAT') FROM sys.dual;

SYS_CONTEXT('USERENV','NLS_DATE_FORMAT')
----------------------------------------
DD-MON-RR

SQL> SELECT sys_context ('USERENV', 'OS_USER') FROM sys.dual;

SYS_CONTEXT('USERENV','OS_USER')
--------------------------------
HALLEY\Administrator

SQL> SELECT sys_context ('USERENV', 'SESSION_USER') FROM sys.dual;

SYS_CONTEXT('USERENV','SESSION_USER')
-------------------------------------
SCOTT

SQL> SELECT banner FROM v$version;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 - Prod
PL/SQL Release 10.1.0.2.0 - Production
CORE    10.1.0.2.0      Production
TNS for 32-bit Windows: Version 10.1.0.2.0 - Production
NLSRTL Version 10.1.0.2.0 - Production

DB2SQL92> SELECT CURRENT_SCHEMA FROM sysibm.sysdummy1;

1
--------
DB2INST1

DB2SQL92> SELECT CURRENT_SERVER FROM sysibm.sysdummy1;

1
------
SAMPLE

DB2SQL92> SELECT USER FROM sysibm.sysdummy1;

1
--------
DB2INST1

-- Linha de comando

$ db2level

DB21085I  A instância "db2inst1" utiliza "32" bits e o release de código do DB2
"SQL08020" com identificador de nível "03010106".
Os tokens informativos são "DB2 v8.1.0.64", "s040812", "MI00086" e FixPak "7".
O produto está instalado em "/opt/IBM/db2/V8.1".