37.7. Категории изменчивости функций #
Для каждой функции определяется характеристика изменчивости, с возможными вариантами: VOLATILE
, STABLE
и IMMUTABLE
. Если эта характеристика не задаётся явно в команде CREATE FUNCTION
, по умолчанию подразумевается VOLATILE
. Категория изменчивости представляет собой обещание некоторого поведения функции для оптимизатора:
Изменчивая функция (
VOLATILE
) может делать всё, что угодно, в том числе, модифицировать базу данных. Она может возвращать различные результаты при нескольких вызовах с одинаковыми аргументами. Оптимизатор не делает никаких предположений о поведении таких функций. В запросе, использующем изменчивую функцию, она будет вычисляться заново для каждой строки, когда потребуется её результат.Стабильная функция (
STABLE
) не может модифицировать базу данных и гарантированно возвращает одинаковый результат, получая одинаковые аргументы, для всех строк в одном операторе. Эта характеристика позволяет оптимизатору заменить множество вызовов этой функции одним. В частности, выражение, содержащее такую функцию, можно безопасно использовать в условии поиска по индексу. (Так как при поиске по индексу целевое значение вычисляется только один раз, а не для каждой строки, использовать функцию с характеристикойVOLATILE
в условии поиска по индексу нельзя.)Постоянная функция (
IMMUTABLE
) не может модифицировать базу данных и гарантированно всегда возвращает одинаковые результаты для одних и тех же аргументов. Эта характеристика позволяет оптимизатору предварительно вычислить функцию, когда она вызывается в запросе с постоянными аргументами. Например, запрос видаSELECT ... WHERE x = 2 + 2
можно упростить доSELECT ... WHERE x = 4
, так как нижележащая функция оператора сложения помечена какIMMUTABLE
.
Для наилучших результатов оптимизации, функции следует назначать самую строгую характеристику изменчивости, которой она соответствует.
Любая функция с побочными эффектами должна быть помечена как VOLATILE
, чтобы обращения к ней не исключались при оптимизации. Даже если функция не имеет побочных эффектов, её нужно пометить как VOLATILE
, если её значение может меняться при выполнении одного запроса; таковы функции random()
, currval()
и timeofday()
.
Другой важный пример представляет семейство функций current_timestamp
, которые имеют характеристику STABLE
, потому что их значения не меняются в рамках одной транзакции.
Характеристики STABLE
и IMMUTABLE
мало различаются, когда речь идёт о простых интерактивных запросах, которые планируются и сразу же выполняются; не имеет большого значения, будет ли функция выполнена однократно на этапе планирования или в начале выполнения. Существенное различие проявляется, когда план сохраняется и многократно используется позже. Если функция помечена как IMMUTABLE
, тогда как на самом деле она не является постоянной, она может быть сведена к константе во время планирования, так что при последующих выполнениях плана вместо неё будет использоваться неактуальное значение. Это опасно при использовании подготовленных операторов или языков функций, кеширующих планы (например, PL/pgSQL).
У функций, написанных на SQL или на любом другом стандартном процедурном языке, есть ещё одно важное свойство, определяемое характеристикой изменчивости, а именно видимость изменений, произведённых командой SQL, которая вызывает эту функцию. Функция VOLATILE
будет видеть такие изменения, тогда как STABLE
и IMMUTABLE
— нет. Это поведение реализуется посредством снимков в MVCC (см. Главу 13): STABLE
и IMMUTABLE
используют снимок, полученный в начале вызывающего запроса, тогда как функции VOLATILE
получают свежий снимок в начале каждого запроса, который они выполняют.
Примечание
Функции, написанные на C, могут работать со снимками как угодно, но обычно лучше сделать так, чтобы они действовали аналогично.
Вследствие такой организации работы со снимками, функцию, содержащую только команды SELECT
, можно безопасно пометить как STABLE
, даже если она выбирает данные из таблиц, которые могут быть изменены параллельными запросами. Postgres Pro выполнит все команды в функции STABLE
со снимком, полученным для вызывающего запроса, так что они будут видеть одно представление базы данных на протяжении всего запроса.
То же самое поведение со снимками распространяется на команды SELECT
в функциях IMMUTABLE
. Вообще в функциях IMMUTABLE
обычно неразумно выбирать данные из таблиц, так как «постоянство» функции будет нарушено, если содержимое таблиц изменится. Однако Postgres Pro не принуждает вас явно отказаться от этого.
Одна из распространённых ошибок — помечать функцию как IMMUTABLE
, при том, что её результаты зависят от параметра конфигурации. Например, функция, работающая с временем, может выдавать результаты, зависящие от параметра TimeZone. Для надёжности такие функции следует помечать как STABLE
.
Примечание
Postgres Pro требует, чтобы функции STABLE
и IMMUTABLE
не содержали SQL-команд, кроме SELECT
, для предотвращения модификации данных. (Это не совсем непробиваемое ограничение, так как эти функции всё же могут вызывать функции VOLATILE
, способные модифицировать базу данных. Если вы реализуете такую схему, вы увидите, что функция STABLE
и IMMUTABLE
не замечает изменений в базе данных, произведённых вызванной функцией, так как они не проявляются в её снимке данных.)
33.7. Canceling Queries in Progress
A client application can request cancellation of a command that is still being processed by the server, using the functions described in this section.
PQgetCancel
Creates a data structure containing the information needed to cancel a command issued through a particular database connection.
PGcancel *PQgetCancel(PGconn *conn);
PQgetCancel
creates aPGcancel
object given aPGconn
connection object. It will returnNULL
if the givenconn
isNULL
or an invalid connection. ThePGcancel
object is an opaque structure that is not meant to be accessed directly by the application; it can only be passed toPQcancel
orPQfreeCancel
.PQfreeCancel
Frees a data structure created by
PQgetCancel
.void PQfreeCancel(PGcancel *cancel);
PQfreeCancel
frees a data object previously created byPQgetCancel
.PQcancel
Requests that the server abandon processing of the current command.
int PQcancel(PGcancel *cancel, char *errbuf, int errbufsize);
The return value is 1 if the cancel request was successfully dispatched and 0 if not. If not,
errbuf
is filled with an explanatory error message.errbuf
must be a char array of sizeerrbufsize
(the recommended size is 256 bytes).Successful dispatch is no guarantee that the request will have any effect, however. If the cancellation is effective, the current command will terminate early and return an error result. If the cancellation fails (say, because the server was already done processing the command), then there will be no visible result at all.
PQcancel
can safely be invoked from a signal handler, if theerrbuf
is a local variable in the signal handler. ThePGcancel
object is read-only as far asPQcancel
is concerned, so it can also be invoked from a thread that is separate from the one manipulating thePGconn
object.
PQrequestCancel
PQrequestCancel
is a deprecated variant ofPQcancel
.int PQrequestCancel(PGconn *conn);
Requests that the server abandon processing of the current command. It operates directly on the
PGconn
object, and in case of failure stores the error message in thePGconn
object (whence it can be retrieved byPQerrorMessage
). Although the functionality is the same, this approach is not safe within multiple-thread programs or signal handlers, since it is possible that overwriting thePGconn
's error message will mess up the operation currently in progress on the connection.