# 45.10. Utility Functions

The `plpy` module also provides the functions

| `plpy.debug(`*`msg, **kwargs`*)   |
| --------------------------------- |
| `plpy.log(`*`msg, **kwargs`*)     |
| `plpy.info(`*`msg, **kwargs`*)    |
| `plpy.notice(`*`msg, **kwargs`*)  |
| `plpy.warning(`*`msg, **kwargs`*) |
| `plpy.error(`*`msg, **kwargs`*)   |
| `plpy.fatal(`*`msg, **kwargs`*)   |

`plpy.error` and `plpy.fatal` actually raise a Python exception which, if uncaught, propagates out to the calling query, causing the current transaction or subtransaction to be aborted. `raise plpy.Error(`*`msg`*) and `raise plpy.Fatal(`*`msg`*) are equivalent to calling `plpy.error(`*`msg`*) and `plpy.fatal(`*`msg`*), respectively but the `raise` form does not allow passing keyword arguments. The other functions only generate messages of different priority levels. Whether messages of a particular priority are reported to the client, written to the server log, or both is controlled by the [log\_min\_messages](https://www.postgresql.org/docs/12/runtime-config-logging.html#GUC-LOG-MIN-MESSAGES) and [client\_min\_messages](https://www.postgresql.org/docs/12/runtime-config-client.html#GUC-CLIENT-MIN-MESSAGES) configuration variables. See [Chapter 19](https://www.postgresql.org/docs/12/runtime-config.html) for more information.

The *`msg`* argument is given as a positional argument. For backward compatibility, more than one positional argument can be given. In that case, the string representation of the tuple of positional arguments becomes the message reported to the client.

The following keyword-only arguments are accepted:

| `detail`          |
| ----------------- |
| `hint`            |
| `sqlstate`        |
| `schema_name`     |
| `table_name`      |
| `column_name`     |
| `datatype_name`   |
| `constraint_name` |

The string representation of the objects passed as keyword-only arguments is used to enrich the messages reported to the client. For example:

```
CREATE FUNCTION raise_custom_exception() RETURNS void AS $$
plpy.error("custom exception message",
           detail="some info about exception",
           hint="hint for users")
$$ LANGUAGE plpythonu;

=# SELECT raise_custom_exception();
ERROR:  plpy.Error: custom exception message
DETAIL:  some info about exception
HINT:  hint for users
CONTEXT:  Traceback (most recent call last):
  PL/Python function "raise_custom_exception", line 4, in <module>
    hint="hint for users")
PL/Python function "raise_custom_exception"
```

Another set of utility functions are `plpy.quote_literal(`*`string`*), `plpy.quote_nullable(`*`string`*), and `plpy.quote_ident(`*`string`*). They are equivalent to the built-in quoting functions described in [Section 9.4](https://www.postgresql.org/docs/12/functions-string.html). They are useful when constructing ad-hoc queries. A PL/Python equivalent of dynamic SQL from [Example 42.1](https://www.postgresql.org/docs/12/plpgsql-statements.html#PLPGSQL-QUOTE-LITERAL-EXAMPLE) would be:

```
plpy.execute("UPDATE tbl SET %s = %s WHERE key = %s" % (
    plpy.quote_ident(colname),
    plpy.quote_nullable(newvalue),
    plpy.quote_literal(keyvalue)))
```


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.postgresql.tw/13/server-programming/pl-python-python-procedural-language-1/utility-functions.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
