Table 4-25. 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 | 
    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. Currently it is always equal to the session
    user, but in the future there might be "setuid" functions and
    other facilities to allow the current user to change temporarily.
    In Unix parlance, the session user is the "real user"
    and the current user is the "effective user".
   
Note that these functions have special syntactic status in SQL: they must be called without trailing parentheses.
Deprecated: The function
getpgusername()is an obsolete equivalent ofcurrent_user.
Table 4-26. System Information Functions
| Name | Return Type | Description | 
|---|---|---|
| version | text | PostgreSQL version information | 
    version() returns a string describing the PostgreSQL
    server's version.
   
Table 4-27. 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_table_privilege determines 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.)  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.)
   
Table 4-28. Catalog Information Functions
| Name | Return Type | Description | 
|---|---|---|
| pg_get_viewdef(viewname) | text | Get CREATE VIEW command for view | 
| pg_get_ruledef(rulename) | text | Get CREATE RULE command for rule | 
| pg_get_indexdef(indexOID) | text | Get CREATE INDEX command for index | 
| pg_get_userbyid(userid) | name | Get user name given ID | 
    These functions extract information from the system catalogs.
    pg_get_viewdef(), pg_get_ruledef(), and
    pg_get_indexdef() respectively reconstruct the creating
    command for a view, rule, or index.  (Note that this is a decompiled
    reconstruction, not the verbatim text of the command.)
    pg_get_userbyid() extracts a user's name given a
    usesysid value.
   
Table 4-29. 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.