PostgreSQL 8.4.22 Documentation | ||||
---|---|---|---|---|
Prev | Fast Backward | Chapter 9. Functions and Operators | Fast Forward | Next |
Table 9-47 shows several functions that extract session and system information.
In addition to the functions listed in this section, there are a number of functions related to the statistics system that also provide system information. See Section 26.2.2 for more information.
Table 9-47. Session Information Functions
Name | Return Type | Description |
---|---|---|
current_catalog |
name | name of current database (called "catalog" in the SQL standard) |
current_database () |
name | name of current database |
current_schema [()] |
name | name of current schema |
current_schemas (boolean) |
name[] | names of schemas in search path, optionally including implicit schemas |
current_user |
name | user name of current execution context |
current_query () |
text | text of the currently executing query, as submitted by the client (might contain more than one statement) |
pg_backend_pid () |
int | Process ID of the server process attached to the current session |
inet_client_addr () |
inet | address of the remote connection |
inet_client_port () |
int | port of the remote connection |
inet_server_addr () |
inet | address of the local connection |
inet_server_port () |
int | port of the local connection |
pg_my_temp_schema () |
oid | OID of session's temporary schema, or 0 if none |
pg_is_other_temp_schema (oid) |
boolean | is schema another session's temporary schema? |
pg_postmaster_start_time () |
timestamp with time zone | server start time |
pg_conf_load_time () |
timestamp with time zone | configuration load time |
session_user |
name | session user name |
user |
name | equivalent to current_user |
version () |
text | PostgreSQL version information |
Note:
current_catalog
,current_schema
,current_user
,session_user
, anduser
have special syntactic status in SQL: they must be called without trailing parentheses. (In PostgreSQL, parentheses can optionally be used withcurrent_schema
, but not with the others.)
The session_user
is normally the
user who initiated the current database connection; but
superusers can change this setting with SET SESSION
AUTHORIZATION. The current_user
is the user identifier that is applicable for permission
checking. Normally it is equal to the session user, but it can be
changed with SET ROLE.
It also 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".
current_schema
returns the name
of the schema that is first in the search path (or a null value
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 returned search path.
Note: The search path can be altered at run time. The command is:
SET search_path TO schema [, schema, ...]
inet_client_addr
returns the IP
address of the current client, and inet_client_port
returns the port number.
inet_server_addr
returns the IP
address on which the server accepted the current connection, and
inet_server_port
returns the port
number. All these functions return NULL if the current connection
is via a Unix-domain socket.
pg_my_temp_schema
returns the
OID of the current session's temporary schema, or zero if it has
none (because it has not created any temporary tables).
pg_is_other_temp_schema
returns
true if the given OID is the OID of another session's temporary
schema. (This can be useful, for example, to exclude other
sessions' temporary tables from a catalog display.)
pg_postmaster_start_time
returns
the timestamp with time zone when the
server started.
pg_conf_load_time
returns the
timestamp with time zone when the server
configuration files were last loaded. (If the current session was
alive at the time, this will be the time when the session itself
re-read the configuration files, so the reading will vary a
little in different sessions. Otherwise it is the time when the
postmaster process re-read the configuration files.)
version
returns a string
describing the PostgreSQL
server's version.
Table 9-48 lists functions that allow the user to query object access privileges programmatically. See Section 5.6 for more information about privileges.
Table 9-48. Access Privilege Inquiry Functions
Name | Return Type | Description |
---|---|---|
has_any_column_privilege (user, table,
privilege) |
boolean | does user have privilege for any column of table |
has_any_column_privilege (table, privilege) |
boolean | does current user have privilege for any column of table |
has_column_privilege (user, table,
column, privilege) |
boolean | does user have privilege for column |
has_column_privilege (table, column, privilege) |
boolean | does current user have privilege for column |
has_database_privilege (user, database, privilege) |
boolean | does user have privilege for database |
has_database_privilege (database, privilege) |
boolean | does current user have privilege for database |
has_foreign_data_wrapper_privilege (user,
fdw, privilege) |
boolean | does user have privilege for foreign-data wrapper |
has_foreign_data_wrapper_privilege (fdw,
privilege) |
boolean | does current user have privilege for foreign-data wrapper |
has_function_privilege (user, function, privilege) |
boolean | does user have privilege for function |
has_function_privilege (function, privilege) |
boolean | does current user have privilege for function |
has_language_privilege (user, language, privilege) |
boolean | does user have privilege for language |
has_language_privilege (language, privilege) |
boolean | does current user have privilege for language |
has_schema_privilege (user, schema,
privilege) |
boolean | does user have privilege for schema |
has_schema_privilege (schema, privilege) |
boolean | does current user have privilege for schema |
has_server_privilege (user, server,
privilege) |
boolean | does user have privilege for foreign server |
has_server_privilege (server, privilege) |
boolean | does current user have privilege for foreign server |
has_table_privilege (user, table,
privilege) |
boolean | does user have privilege for table |
has_table_privilege (table, privilege) |
boolean | does current user have privilege for table |
has_tablespace_privilege (user, tablespace, privilege) |
boolean | does user have privilege for tablespace |
has_tablespace_privilege (tablespace, privilege) |
boolean | does current user have privilege for tablespace |
pg_has_role (user, role,
privilege) |
boolean | does user have privilege for role |
pg_has_role (role, privilege) |
boolean | does current user have privilege for role |
has_table_privilege
checks
whether a user can access a table in a particular way. The user
can be specified by name or by OID (pg_authid.oid), 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 privilege type
is specified by a text string, which must evaluate to one of the
values SELECT, INSERT, UPDATE,
DELETE, TRUNCATE, REFERENCES, or
TRIGGER. Optionally, WITH GRANT OPTION can be added to a privilege type
to test whether the privilege is held with grant option. Also,
multiple privilege types can be listed separated by commas, in
which case the result will be true if
any of the listed privileges is held. (Case of the privilege
string is not significant, and extra whitespace is allowed
between but not within privilege names.) Some examples:
SELECT has_table_privilege('myschema.mytable', 'select'); SELECT has_table_privilege('joe', 'mytable', 'INSERT, SELECT WITH GRANT OPTION');
has_any_column_privilege
checks
whether a user can access any column of a table in a particular
way. Its argument possibilities are analogous to has_table_privilege
, except that the desired
access privilege type must evaluate to some combination of
SELECT, INSERT,
UPDATE, or REFERENCES. Note that having any of these
privileges at the table level implicitly grants it for each
column of the table, so has_any_column_privilege
will always return
true if has_table_privilege
does for the same
arguments. But has_any_column_privilege
also succeeds if there
is a column-level grant of the privilege for at least one
column.
has_column_privilege
checks
whether a user can access a column in a particular way. Its
argument possibilities are analogous to has_table_privilege
, with the addition that the
column can be specified either by name or attribute number. The
desired access privilege type must evaluate to some combination
of SELECT, INSERT, UPDATE, or
REFERENCES. Note that having any of
these privileges at the table level implicitly grants it for each
column of the table.
has_database_privilege
checks
whether a user can access a database in a particular way. Its
argument possibilities are analogous to has_table_privilege
. The desired access
privilege type must evaluate to some combination of CREATE, CONNECT,
TEMPORARY, or TEMP (which is equivalent to TEMPORARY).
has_function_privilege
checks
whether a user can access a function in a particular way. Its
argument possibilities 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 data type (see
Section 8.16). The desired access
privilege type must evaluate to EXECUTE.
An example is:
SELECT has_function_privilege('joeuser', 'myfunc(int, text)', 'execute');
has_foreign_data_wrapper_privilege
checks
whether a user can access a foreign-data wrapper in a particular
way. Its argument possibilities are analogous to has_table_privilege
. The desired access
privilege type must evaluate to USAGE.
has_language_privilege
checks
whether a user can access a procedural language in a particular
way. Its argument possibilities are analogous to has_table_privilege
. The desired access
privilege type must evaluate to USAGE.
has_schema_privilege
checks
whether a user can access a schema in a particular way. Its
argument possibilities are analogous to has_table_privilege
. The desired access
privilege type must evaluate to some combination of CREATE or USAGE.
has_server_privilege
checks
whether a user can access a foreign server in a particular way.
Its argument possibilities are analogous to has_table_privilege
. The desired access
privilege type must evaluate to USAGE.
has_tablespace_privilege
checks
whether a user can access a tablespace in a particular way. Its
argument possibilities are analogous to has_table_privilege
. The desired access
privilege type must evaluate to CREATE.
pg_has_role
checks whether a
user can access a role in a particular way. Its argument
possibilities are analogous to has_table_privilege
. The desired access
privilege type must evaluate to some combination of MEMBER or USAGE.
MEMBER denotes direct or indirect
membership in the role (that is, the right to do SET ROLE), while USAGE
denotes whether the privileges of the role are immediately
available without doing SET ROLE.
Table 9-49 shows functions that determine whether a certain object is visible in the current schema search path. For example, 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. To list the names of all visible tables:
SELECT relname FROM pg_class WHERE pg_table_is_visible(oid);
Table 9-49. Schema Visibility Inquiry Functions
Name | Return Type | Description |
---|---|---|
pg_conversion_is_visible (conversion_oid) |
boolean | is conversion visible in search path |
pg_function_is_visible (function_oid) |
boolean | is function visible in search path |
pg_operator_is_visible (operator_oid) |
boolean | is operator visible in search path |
pg_opclass_is_visible (opclass_oid) |
boolean | is operator class visible in search path |
pg_table_is_visible (table_oid) |
boolean | is table visible in search path |
pg_ts_config_is_visible (config_oid) |
boolean | is text search configuration visible in search path |
pg_ts_dict_is_visible (dict_oid) |
boolean | is text search dictionary visible in search path |
pg_ts_parser_is_visible (parser_oid) |
boolean | is text search parser visible in search path |
pg_ts_template_is_visible (template_oid) |
boolean | is text search template visible in search path |
pg_type_is_visible (type_oid) |
boolean | is type (or domain) visible in search path |
Each function performs the visibility check for one type of
database object. Note that pg_table_is_visible
can also be used with
views, indexes and sequences; pg_type_is_visible
can also be used with
domains. For functions and operators, an object in the search
path is visible if there is no object of the same name
and argument data
type(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, regoperator, regconfig, or regdictionary), for example:
SELECT pg_type_is_visible('myschema.widget'::regtype);
Note that it would not make much sense to test a non-schema-qualified type name in this way — if the name can be recognized at all, it must be visible.
Table 9-50 lists functions that extract information from the system catalogs.
Table 9-50. System Catalog Information Functions
Name | Return Type | Description |
---|---|---|
format_type (type_oid, typemod) |
text | get SQL name of a data type |
pg_get_keywords () |
setof record | get list of SQL keywords and their categories |
pg_get_constraintdef (constraint_oid) |
text | get definition of a constraint |
pg_get_constraintdef (constraint_oid, pretty_bool) |
text | get definition of a constraint |
pg_get_expr (expr_text, relation_oid) |
text | decompile internal form of an expression, assuming that any Vars in it refer to the relation indicated by the second parameter |
pg_get_expr (expr_text, relation_oid, pretty_bool) |
text | decompile internal form of an expression, assuming that any Vars in it refer to the relation indicated by the second parameter |
pg_get_functiondef (func_oid) |
text | get definition of a function |
pg_get_function_arguments (func_oid) |
text | get argument list of function's definition (with default values) |
pg_get_function_identity_arguments (func_oid) |
text | get argument list to identify a function (without default values) |
pg_get_function_result (func_oid) |
text | get RETURNS clause for function |
pg_get_indexdef (index_oid) |
text | get CREATE INDEX command for index |
pg_get_indexdef (index_oid, column_no, pretty_bool) |
text | get CREATE INDEX command for index, or definition of just one index column when column_no is not zero |
pg_get_ruledef (rule_oid) |
text | get CREATE RULE command for rule |
pg_get_ruledef (rule_oid, pretty_bool) |
text | get CREATE RULE command for rule |
pg_get_serial_sequence (table_name, column_name) |
text | get name of the sequence that a serial or bigserial column uses |
pg_get_triggerdef (trigger_oid) |
text | get CREATE [ CONSTRAINT ] TRIGGER command for trigger |
pg_get_userbyid (role_oid) |
name | get role name with given OID |
pg_get_viewdef (view_name) |
text | get underlying SELECT command for view (deprecated) |
pg_get_viewdef (view_name, pretty_bool) |
text | get underlying SELECT command for view (deprecated) |
pg_get_viewdef (view_oid) |
text | get underlying SELECT command for view |
pg_get_viewdef (view_oid, pretty_bool) |
text | get underlying SELECT command for view |
pg_tablespace_databases (tablespace_oid) |
setof oid | get the set of database OIDs that have objects in the tablespace |
pg_typeof (any) |
regtype | get the data type of any value |
format_type
returns the SQL name
of a data type that is identified by its type OID and possibly a
type modifier. Pass NULL for the type modifier if no specific
modifier is known.
pg_get_keywords
returns a set of
records describing the SQL keywords recognized by the server. The
word column contains the keyword.
The catcode column contains a
category code: U for unreserved,
C for column name, T for type or function name, or R for reserved. The catdesc column contains a possibly-localized
string describing the category.
pg_get_constraintdef
,
pg_get_indexdef
, pg_get_ruledef
, and pg_get_triggerdef
, respectively reconstruct the
creating command for a constraint, index, rule, or trigger. (Note
that this is a decompiled reconstruction, not the original text
of the command.) pg_get_expr
decompiles the internal form of an individual expression, such as
the default value for a column. It can be useful when examining
the contents of system catalogs. If the expression might contain
Vars, specify the OID of the relation they refer to as the second
parameter; if no Vars are expected, zero is sufficient.
pg_get_viewdef
reconstructs the
SELECT query that defines a view. Most
of these functions come in two variants, one of which can
optionally "pretty-print" the result.
The pretty-printed format is more readable, but the default
format is more likely to be interpreted the same way by future
versions of PostgreSQL; avoid
using pretty-printed output for dump purposes. Passing false for the pretty-print parameter yields the
same result as the variant that does not have the parameter at
all.
pg_get_functiondef
returns a
complete CREATE OR REPLACE FUNCTION
statement for a function. pg_get_function_arguments
returns the argument
list of a function, in the form it would need to appear in within
CREATE FUNCTION. pg_get_function_result
similarly returns the
appropriate RETURNS clause for the
function. pg_get_function_identity_arguments
returns the
argument list necessary to identify a function, in the form it
would need to appear in within ALTER
FUNCTION, for instance. This form omits default values.
pg_get_serial_sequence
returns
the name of the sequence associated with a column, or NULL if no
sequence is associated with the column. The first input parameter
is a table name with optional schema, and the second parameter is
a column name. Because the first parameter is potentially a
schema and table, it is not treated as a double-quoted
identifier, meaning it is lowercased by default, while the second
parameter, being just a column name, is treated as double-quoted
and has its case preserved. The function returns a value suitably
formatted for passing to sequence functions (see Section 9.15). This association can
be modified or removed with ALTER SEQUENCE
OWNED BY. (The function probably should have been called
pg_get_owned_sequence
; its current
name reflects the fact that it's typically used with serial or bigserial
columns.)
pg_get_userbyid
extracts a
role's name given its OID.
pg_tablespace_databases
allows a
tablespace to be examined. It returns the set of OIDs of
databases that have objects stored in the tablespace. If this
function returns any rows, the tablespace is not empty and cannot
be dropped. To display the specific objects populating the
tablespace, you will need to connect to the databases identified
by pg_tablespace_databases
and
query their pg_class catalogs.
pg_typeof
returns the OID of the
data type of the value that is passed to it. This can be helpful
for troubleshooting or dynamically constructing SQL queries. The
function is declared as returning regtype,
which is an OID alias type (see Section 8.16); this means that it is the
same as an OID for comparison purposes but displays as a type
name. For example:
SELECT pg_typeof(33); pg_typeof ----------- integer (1 row) SELECT typlen FROM pg_type WHERE oid = pg_typeof(33); typlen -------- 4 (1 row)
The functions shown in Table 9-51 extract comments previously stored with the COMMENT command. A null value is returned if no comment could be found for the specified parameters.
Table 9-51. Comment Information Functions
Name | Return Type | Description |
---|---|---|
col_description (table_oid, column_number) |
text | get comment for a table column |
obj_description (object_oid, catalog_name) |
text | get comment for a database object |
obj_description (object_oid) |
text | get comment for a database object (deprecated) |
shobj_description (object_oid, catalog_name) |
text | get comment for a shared database object |
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.
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 the table with OID 123456. The one-parameter form
of obj_description
requires only
the object OID. It is deprecated since there is no guarantee that
OIDs are unique across different system catalogs; therefore, the
wrong comment might be returned.
shobj_description
is used just
like obj_description
except it is
used for retrieving comments on shared objects. Some system
catalogs are global to all databases within each cluster and
their descriptions are stored globally as well.
The functions shown in Table 9-52 provide server transaction information in an exportable form. The main use of these functions is to determine which transactions were committed between two snapshots.
Table 9-52. Transaction IDs and snapshots
Name | Return Type | Description |
---|---|---|
txid_current () |
bigint | get current transaction ID |
txid_current_snapshot () |
txid_snapshot | get current snapshot |
txid_snapshot_xmin (txid_snapshot) |
bigint | get xmin of snapshot |
txid_snapshot_xmax (txid_snapshot) |
bigint | get xmax of snapshot |
txid_snapshot_xip (txid_snapshot) |
setof bigint | get in-progress transaction IDs in snapshot |
txid_visible_in_snapshot (bigint, txid_snapshot) |
boolean | is transaction ID visible in snapshot? (do not use with subtransaction ids) |
The internal transaction ID type (xid) is 32 bits wide and wraps around every 4 billion transactions. However, these functions export a 64-bit format that is extended with an "epoch" counter so it will not wrap around during the life of an installation. The data type used by these functions, txid_snapshot, stores information about transaction ID visibility at a particular moment in time. Its components are described in Table 9-53.
Table 9-53. Snapshot components
Name | Description |
---|---|
xmin | Earliest transaction ID (txid) that is still active. All earlier transactions will either be committed and visible, or rolled back and dead. |
xmax | First as-yet-unassigned txid. All txids greater than or equal to this are not yet started as of the time of the snapshot, and thus invisible. |
xip_list | Active txids at the time of the snapshot. The list includes only those active txids between xmin and xmax; there might be active txids higher than xmax. A txid that is xmin <= txid < xmax and not in this list was already completed at the time of the snapshot, and thus either visible or dead according to its commit status. The list does not include txids of subtransactions. |
txid_snapshot's textual representation is xmin:xmax:xip_list. For example 10:20:10,14,15 means xmin=10, xmax=20, xip_list=10, 14, 15.