Table 6-26. Session Information Functions
Name | Return Type | Description |
---|---|---|
current_user | name | user name of current execution context |
session_user | name | session user name |
user | name | equivalent to current_user |
current_schema() | name | name of current schema |
current_schemas(boolean) | name[] | names of schemas in search path optionally including implicit schemas |
current_database() | name | name of current database |
The session_user is the user that initiated a database connection; it is fixed for the duration of that connection. The current_user is the user identifier that is applicable for permission checking. Normally, it is equal to the session user, but it changes during the execution of functions with the attribute SECURITY DEFINER. In Unix parlance, the session user is the "real user" and the current user is the "effective user".
Note: current_user, session_user, and user have special syntactic status in SQL: they must be called without trailing parentheses.
Deprecated: The function getpgusername() is an obsolete equivalent of current_user.
current_schema returns the name of the schema that is at the front of the search path (or NULL if the search path is empty). This is the schema that will be used for any tables or other named objects that are created without specifying a target schema. current_schemas(boolean) returns an array of the names of all schemas presently in the search path. The boolean option determines whether or not implicitly included system schemas such as pg_catalog are included in the search path returned.
The search path may be altered by a runtime-alterable GUC setting. The command to use is SET SEARCH_PATH 'schema'[,'schema']...
Table 6-27. System Information Functions
Name | Return Type | Description |
---|---|---|
version | text | PostgreSQL version information |
version() returns a string describing the PostgreSQL server's version.
Table 6-28. Configuration Settings Information Functions
Name | Return Type | Description |
---|---|---|
current_setting(setting_name) | text | value of current setting |
set_config(setting_name, new_value, is_local) | text | new value of current setting |
The current_setting is used to obtain the current value of the setting_name setting, as a query result. It is the equivalent to the SQL SHOW command. For example:
select current_setting('DateStyle'); current_setting --------------------------------------- ISO with US (NonEuropean) conventions (1 row)
set_config allows the setting_name setting to be changed to new_value. If is_local is set to true, the new value will only apply to the current transaction. If you want the new value to apply for the current session, use false instead. It is the equivalent to the SQL SET command. For example:
select set_config('show_statement_stats','off','f'); set_config ------------ off (1 row)
Table 6-29. Access Privilege Inquiry Functions
Name | Return Type | Description |
---|---|---|
has_table_privilege(user, table, access) | boolean | does user have access to table |
has_table_privilege(table, access) | boolean | does current user have access to table |
has_database_privilege(user, database, access) | boolean | does user have access to database |
has_database_privilege(database, access) | boolean | does current user have access to database |
has_function_privilege(user, function, access) | boolean | does user have access to function |
has_function_privilege(function, access) | boolean | does current user have access to function |
has_language_privilege(user, language, access) | boolean | does user have access to language |
has_language_privilege(language, access) | boolean | does current user have access to language |
has_schema_privilege(user, schema, access) | boolean | does user have access to schema |
has_schema_privilege(schema, access) | boolean | does current user have access to schema |
has_table_privilege checks whether a user can access a table in a particular way. The user can be specified by name or by ID (pg_user.usesysid), or if the argument is omitted current_user is assumed. The table can be specified by name or by OID. (Thus, there are actually six variants of has_table_privilege, which can be distinguished by the number and types of their arguments.) When specifying by name, the name can be schema-qualified if necessary. The desired access type is specified by a text string, which must evaluate to one of the values SELECT, INSERT, UPDATE, DELETE, RULE, REFERENCES, or TRIGGER. (Case of the string is not significant, however.) An example is:
SELECT has_table_privilege('myschema.mytable', 'select');
has_database_privilege checks whether a user can access a database in a particular way. The possibilities for its arguments are analogous to has_table_privilege. The desired access type must evaluate to CREATE, TEMPORARY, or TEMP (which is equivalent to TEMPORARY).
has_function_privilege checks whether a user can access a function in a particular way. The possibilities for its arguments are analogous to has_table_privilege. When specifying a function by a text string rather than by OID, the allowed input is the same as for the regprocedure datatype. The desired access type must currently evaluate to EXECUTE.
has_language_privilege checks whether a user can access a procedural language in a particular way. The possibilities for its arguments are analogous to has_table_privilege. The desired access type must currently evaluate to USAGE.
has_schema_privilege checks whether a user can access a schema in a particular way. The possibilities for its arguments are analogous to has_table_privilege. The desired access type must evaluate to CREATE or USAGE.
Table 6-30. Schema Visibility Inquiry Functions
Name | Return Type | Description |
---|---|---|
pg_table_is_visible(tableOID) | boolean | is table visible in search path |
pg_type_is_visible(typeOID) | boolean | is type visible in search path |
pg_function_is_visible(functionOID) | boolean | is function visible in search path |
pg_operator_is_visible(operatorOID) | boolean | is operator visible in search path |
pg_opclass_is_visible(opclassOID) | boolean | is operator class visible in search path |
pg_table_is_visible checks whether a table (or view, or any other kind of pg_class entry) is visible in the current schema search path. A table is said to be visible if its containing schema is in the search path and no table of the same name appears earlier in the search path. This is equivalent to the statement that the table can be referenced by name without explicit schema qualification. For example, to list the names of all visible tables:
SELECT relname FROM pg_class WHERE pg_table_is_visible(oid);
pg_type_is_visible, pg_function_is_visible, pg_operator_is_visible, and pg_opclass_is_visible perform the same sort of visibility check for types, functions, operators, and operator classes, respectively. For functions and operators, an object in the search path is visible if there is no object of the same name and argument datatype(s) earlier in the path. For operator classes, both name and associated index access method are considered.
All these functions require object OIDs to identify the object to be checked. If you want to test an object by name, it is convenient to use the OID alias types (regclass, regtype, regprocedure, or regoperator), for example
SELECT pg_type_is_visible('myschema.widget'::regtype);
Note that it would not make much sense to test an unqualified name in this way --- if the name can be recognized at all, it must be visible.
Table 6-31. Catalog Information Functions
Name | Return Type | Description |
---|---|---|
pg_get_viewdef(viewname) | text | Get CREATE VIEW command for view |
pg_get_viewdef(viewOID) | text | Get CREATE VIEW command for view |
pg_get_ruledef(ruleOID) | text | Get CREATE RULE command for rule |
pg_get_indexdef(indexOID) | text | Get CREATE INDEX command for index |
pg_get_constraintdef(constraintOID) | text | Get definition of a constraint |
pg_get_userbyid(userid) | name | Get user name given ID |
These functions extract information from the system catalogs. pg_get_viewdef(), pg_get_ruledef(), pg_get_indexdef(), and pg_get_constraintdef() respectively reconstruct the creating command for a view, rule, index, or constraint. (Note that this is a decompiled reconstruction, not the verbatim text of the command.) At present pg_get_constraintdef() only works for foreign-key constraints. pg_get_userbyid() extracts a user's name given a usesysid value.
Table 6-32. Comment Information Functions
Name | Return Type | Description |
---|---|---|
obj_description(objectOID, tablename) | text | Get comment for a database object |
obj_description(objectOID) | text | Get comment for a database object (deprecated) |
col_description(tableOID, columnnumber) | text | Get comment for a table column |
These functions extract comments previously stored with the COMMENT command. NULL is returned if no comment can be found matching the specified parameters.
The two-parameter form of obj_description() returns the comment for a database object specified by its OID and the name of the containing system catalog. For example, obj_description(123456,'pg_class') would retrieve the comment for a table with OID 123456. The one-parameter form of obj_description() requires only the object OID. It is now deprecated since there is no guarantee that OIDs are unique across different system catalogs; therefore, the wrong comment could be returned.
col_description() returns the comment for a table column, which is specified by the OID of its table and its column number. obj_description() cannot be used for table columns since columns do not have OIDs of their own.