DECLARE
DECLARE — определить курсор
Синтаксис
DECLAREимя
[ BINARY ] [ ASENSITIVE | INSENSITIVE ] [ [ NO ] SCROLL ] CURSOR [ { WITH | WITHOUT } HOLD ] FORquery
Описание
Оператор DECLARE
позволяет пользователю создавать курсоры, с помощью которых можно выбирать по очереди некоторое количество строк из результата большого запроса. Когда курсор создан, через него можно получать строки, применяя команду FETCH
.
Примечание
На этой странице описывается применение курсоров на уровне команд SQL. Если вы попытаетесь использовать курсоры внутри функции PL/pgSQL, правила будут другими — см. Раздел 41.7.
Параметры
имя
Имя создаваемого курсора. Оно должно отличаться от имён других активных курсоров в сеансе.
BINARY
Курсор с таким свойством возвращает данные в двоичном, а не текстовом формате.
ASENSITIVE
INSENSITIVE
Свойство «чувствительности» курсора определяет, будут ли изменения нижележащих данных курсора, выполненные в той же транзакции после объявления курсора, видны в нём.
INSENSITIVE
означает, что они не будут видны, аASENSITIVE
выбирает поведение, определяемое реализацией. Третий вариант,SENSITIVE
, при выборе которого такие изменения должны быть видны в курсоре, в PostgreSQL не поддерживается. В PostgreSQL все курсоры являются «нечувствительными», поэтому данные ключевые слова не действуют и принимаются только для совместимости со стандартом SQL.Указание
INSENSITIVE
вместе сFOR UPDATE
илиFOR SHARE
считается ошибочным.SCROLL
NO SCROLL
Указание
SCROLL
определяет, что курсор может прокручивать набор данных и получать строки непоследовательно (например, в обратном порядке). В зависимости от сложности плана запроса указаниеSCROLL
может отрицательно отразиться на скорости выполнения запроса. УказаниеNO SCROLL
, напротив, определяет, что через курсор нельзя будет получать строки в произвольном порядке. По умолчанию прокрутка в некоторых случаях разрешается; но это не равнозначно эффекту указанияSCROLL
. За подробностями обратитесь к разделу Замечания.WITH HOLD
WITHOUT HOLD
Указание
WITH HOLD
определяет, что курсор можно продолжать использовать после успешной фиксации создавшей его транзакции.WITHOUT HOLD
определяет, что курсор нельзя будет использовать за рамками транзакции, создавшей его. Если не указано ниWITHOUT HOLD
, ниWITH HOLD
, по умолчанию подразумеваетсяWITHOUT HOLD
.query
Команда
SELECT
илиVALUES
, выдающая строки, которые будут получены через курсор.
Ключевые слова ASENSITIVE
, BINARY
, INSENSITIVE
и SCROLL
могут указываться в любом порядке.
Замечания
Обычный курсор выдаёт данные в текстовом виде, в каком их выдаёт SELECT
. Однако с указанием BINARY
курсор может выдавать их и в двоичном формате. Это упрощает операции преобразования данных для сервера и клиента, за счёт дополнительных усилий, требующихся от программиста для работы с платформозависимыми двоичными форматами. Например, если запрос получает значение 1 из целочисленного столбца, обычный курсор выдаст строку, содержащую 1
, тогда как через двоичный курсор будет получено четырёхбайтовое поле, содержащее внутреннее представление значения (с сетевым порядком байтов).
Двоичные курсоры должны применяться с осмотрительностью. Многие приложения, в том числе psql, не приспособлены к работе с двоичными курсорами и ожидают, что данные будут поступать в текстовом формате.
Примечание
Когда клиентское приложение выполняет команду FETCH
, используя «расширенный» протокол запросов, в сообщении Bind этого протокола указывается, в каком формате, текстовом или двоичном, должны быть получены данные. Это указание переопределяет свойство курсора, заданное в его объявлении. Таким образом, концепция курсора, объявляемого двоичным, становится устаревшей при использовании расширенного протокола запросов — любой курсор может быть прочитан как текстовый или двоичный.
Если в команде объявления курсора не указано WITH HOLD
, созданный ей курсор может использоваться только в текущей транзакции. Таким образом, оператор DECLARE
без WITH HOLD
бесполезен вне блока транзакции: курсор будет существовать только до завершения этого оператора. Поэтому PostgreSQL сообщает об ошибке, если такая команда выполняется вне блока транзакции. Чтобы определить блок транзакции, примените команды BEGIN
и COMMIT
(или ROLLBACK
).
Если в объявлении курсора указано WITH HOLD
и транзакция, создавшая курсор, успешно фиксируется, к этому курсору могут продолжать обращаться последующие транзакции в этом сеансе. (Но если создавшая курсор транзакция прерывается, курсор уничтожается.) Курсор со свойством WITH HOLD
(удерживаемый) может быть закрыт явно, командой CLOSE
, либо неявно, по завершении сеанса. В текущей реализации строки, представляемые удерживаемым курсором, копируются во временный файл или в область памяти, так что они остаются доступными для следующих транзакций.
Объявить курсор со свойством WITH HOLD
можно, только если запрос не содержит указаний FOR UPDATE
и FOR SHARE
.
Указание SCROLL
добавляется при определении курсора, который будет выбирать данные в обратном порядке. Это поведение требуется стандартом SQL. Однако для совместимости с предыдущими версиями, PostgreSQL допускает выборку в обратном направлении и без указания SCROLL
, если план запроса курсора достаточно прост, чтобы реализовать прокрутку назад без дополнительных операций. Тем не менее разработчикам приложений не следует рассчитывать на то, что курсор, созданный без указания SCROLL
, можно будет прокручивать назад. С указанием NO SCROLL
прокрутка назад запрещается в любом случае.
Выборка в обратном направлении также запрещается, если запрос содержит указания FOR UPDATE
и FOR SHARE
; в этом случае указание SCROLL
не принимается.
Внимание
Прокручиваемые курсоры могут выдавать неожиданные результаты, если они вызывают изменчивые функции (см. Раздел 36.7). Когда повторно выбирается ранее прочитанная строка, функции могут вызываться снова и выдавать результаты, отличные от полученных в первый раз. Для запроса, вызывающего изменчивые функции, лучше всего указать NO SCROLL
. Если такой способ не подходит, другая возможность обойти эту проблему — объявить курсор с указанием WITH HOLD
и зафиксировать транзакцию, прежде чем читать из него какие-либо строки. В этом случае весь набор данных курсора будет материализован во временном хранилище, так что изменчивые функции будут выполнены для каждой строки лишь единожды.
Если запрос в определении курсора включает указания FOR UPDATE
или FOR SHARE
, возвращаемые курсором строки блокируются в момент первой выборки, так же, как это происходит при выполнении SELECT
с этими указаниями. Кроме того, при чтении строк будут возвращаться их наиболее актуальные версии.
Внимание
Обычно рекомендуется использовать FOR UPDATE
, если курсор предназначается для применения в командах UPDATE ... WHERE CURRENT OF
и DELETE ... WHERE CURRENT OF
. Указание FOR UPDATE
предотвращает изменение строк другими сеансами после того, как они были считаны, и до того, как выполнится команда. Без FOR UPDATE
последующая команда с WHERE CURRENT OF
не сработает, если строка будет изменена после создания курсора.
Ещё одна причина использовать указание FOR UPDATE
в том, что без него последующие команды с WHERE CURRENT OF
могут выдать ошибку, если запрос курсора не удовлетворяет оговоренному в стандарте SQL критерию «простой изменяемости» (в частности, курсор должен ссылаться только на одну таблицу и не должен использовать группировку и сортировку (ORDER BY
)). Курсоры, не удовлетворяющие этому критерию, могут работать либо не работать, в зависимости от конкретного выбранного плана; так что в худшем случае приложение может работать в тестовой, но сломается в производственной среде. С указанием FOR UPDATE
курсор гарантированно будет изменяемым.
Не использовать же FOR UPDATE
для команд с WHERE CURRENT OF
в основном имеет смысл, только если требуется получить прокручиваемый курсор или курсор, изолированный от одновременно производимых изменений (то есть, продолжающий показывать прежние данные). Если это действительно необходимо, обязательно учтите при реализации приведённые выше замечания.
В стандарте SQL механизм курсоров предусмотрен только для встраиваемого SQL. Сервер PostgreSQL не реализует для курсоров оператор OPEN
; курсор считается открытым при объявлении. Однако ECPG, встраиваемый препроцессор SQL для PostgreSQL, следует соглашениям стандарта, в том числе поддерживая для курсоров операторы DECLARE
и OPEN
.
Структура данных сервера, определяющая открытый курсор, называется порталом. Имена порталов раскрываются в клиентском протоколе, то есть если имя портала известно, клиент может выбирать строки напрямую через открытый портал. Если курсор создаётся командой DECLARE
, имя портала совпадает с именем курсора.
Получить список всех доступных курсоров можно, обратившись к системному представлению pg_cursors
.
Примеры
Объявление курсора:
DECLARE liahona CURSOR FOR SELECT * FROM films;
Другие примеры использования курсора можно найти в FETCH.
Совместимость
Стандарт SQL допускает курсоры только во встраиваемом SQL и в модулях. PostgreSQL позволяет использовать курсоры интерактивно.
Согласно стандарту SQL, изменения, которые вносит нечувствительный курсор, выполняющий оператор UPDATE ... WHERE CURRENT OF
и DELETE ... WHERE CURRENT OF
, должны быть видны в этом же курсоре. PostgreSQL обрабатывает эти операторы как и любые другие операторы, изменяющие данные, так что нечувствительные курсоры не видят результатов их действия.
Двоичные курсоры являются расширением PostgreSQL.
DECLARE
DECLARE — define a cursor
Synopsis
DECLAREname
[ BINARY ] [ ASENSITIVE | INSENSITIVE ] [ [ NO ] SCROLL ] CURSOR [ { WITH | WITHOUT } HOLD ] FORquery
Description
DECLARE
allows a user to create cursors, which can be used to retrieve a small number of rows at a time out of a larger query. After the cursor is created, rows are fetched from it using FETCH
.
Note
This page describes usage of cursors at the SQL command level. If you are trying to use cursors inside a PL/pgSQL function, the rules are different — see Section 41.7.
Parameters
name
The name of the cursor to be created. This must be different from any other active cursor name in the session.
BINARY
Causes the cursor to return data in binary rather than in text format.
ASENSITIVE
INSENSITIVE
Cursor sensitivity determines whether changes to the data underlying the cursor, done in the same transaction, after the cursor has been declared, are visible in the cursor.
INSENSITIVE
means they are not visible,ASENSITIVE
means the behavior is implementation-dependent. A third behavior,SENSITIVE
, meaning that such changes are visible in the cursor, is not available in PostgreSQL. In PostgreSQL, all cursors are insensitive; so these key words have no effect and are only accepted for compatibility with the SQL standard.Specifying
INSENSITIVE
together withFOR UPDATE
orFOR SHARE
is an error.SCROLL
NO SCROLL
SCROLL
specifies that the cursor can be used to retrieve rows in a nonsequential fashion (e.g., backward). Depending upon the complexity of the query's execution plan, specifyingSCROLL
might impose a performance penalty on the query's execution time.NO SCROLL
specifies that the cursor cannot be used to retrieve rows in a nonsequential fashion. The default is to allow scrolling in some cases; this is not the same as specifyingSCROLL
. See Notes below for details.WITH HOLD
WITHOUT HOLD
WITH HOLD
specifies that the cursor can continue to be used after the transaction that created it successfully commits.WITHOUT HOLD
specifies that the cursor cannot be used outside of the transaction that created it. If neitherWITHOUT HOLD
norWITH HOLD
is specified,WITHOUT HOLD
is the default.query
A
SELECT
orVALUES
command which will provide the rows to be returned by the cursor.
The key words ASENSITIVE
, BINARY
, INSENSITIVE
, and SCROLL
can appear in any order.
Notes
Normal cursors return data in text format, the same as a SELECT
would produce. The BINARY
option specifies that the cursor should return data in binary format. This reduces conversion effort for both the server and client, at the cost of more programmer effort to deal with platform-dependent binary data formats. As an example, if a query returns a value of one from an integer column, you would get a string of 1
with a default cursor, whereas with a binary cursor you would get a 4-byte field containing the internal representation of the value (in big-endian byte order).
Binary cursors should be used carefully. Many applications, including psql, are not prepared to handle binary cursors and expect data to come back in the text format.
Note
When the client application uses the “extended query” protocol to issue a FETCH
command, the Bind protocol message specifies whether data is to be retrieved in text or binary format. This choice overrides the way that the cursor is defined. The concept of a binary cursor as such is thus obsolete when using extended query protocol — any cursor can be treated as either text or binary.
Unless WITH HOLD
is specified, the cursor created by this command can only be used within the current transaction. Thus, DECLARE
without WITH HOLD
is useless outside a transaction block: the cursor would survive only to the completion of the statement. Therefore PostgreSQL reports an error if such a command is used outside a transaction block. Use BEGIN
and COMMIT
(or ROLLBACK
) to define a transaction block.
If WITH HOLD
is specified and the transaction that created the cursor successfully commits, the cursor can continue to be accessed by subsequent transactions in the same session. (But if the creating transaction is aborted, the cursor is removed.) A cursor created with WITH HOLD
is closed when an explicit CLOSE
command is issued on it, or the session ends. In the current implementation, the rows represented by a held cursor are copied into a temporary file or memory area so that they remain available for subsequent transactions.
WITH HOLD
may not be specified when the query includes FOR UPDATE
or FOR SHARE
.
The SCROLL
option should be specified when defining a cursor that will be used to fetch backwards. This is required by the SQL standard. However, for compatibility with earlier versions, PostgreSQL will allow backward fetches without SCROLL
, if the cursor's query plan is simple enough that no extra overhead is needed to support it. However, application developers are advised not to rely on using backward fetches from a cursor that has not been created with SCROLL
. If NO SCROLL
is specified, then backward fetches are disallowed in any case.
Backward fetches are also disallowed when the query includes FOR UPDATE
or FOR SHARE
; therefore SCROLL
may not be specified in this case.
Caution
Scrollable cursors may give unexpected results if they invoke any volatile functions (see Section 36.7). When a previously fetched row is re-fetched, the functions might be re-executed, perhaps leading to results different from the first time. It's best to specify NO SCROLL
for a query involving volatile functions. If that is not practical, one workaround is to declare the cursor SCROLL WITH HOLD
and commit the transaction before reading any rows from it. This will force the entire output of the cursor to be materialized in temporary storage, so that volatile functions are executed exactly once for each row.
If the cursor's query includes FOR UPDATE
or FOR SHARE
, then returned rows are locked at the time they are first fetched, in the same way as for a regular SELECT
command with these options. In addition, the returned rows will be the most up-to-date versions.
Caution
It is generally recommended to use FOR UPDATE
if the cursor is intended to be used with UPDATE ... WHERE CURRENT OF
or DELETE ... WHERE CURRENT OF
. Using FOR UPDATE
prevents other sessions from changing the rows between the time they are fetched and the time they are updated. Without FOR UPDATE
, a subsequent WHERE CURRENT OF
command will have no effect if the row was changed since the cursor was created.
Another reason to use FOR UPDATE
is that without it, a subsequent WHERE CURRENT OF
might fail if the cursor query does not meet the SQL standard's rules for being “simply updatable” (in particular, the cursor must reference just one table and not use grouping or ORDER BY
). Cursors that are not simply updatable might work, or might not, depending on plan choice details; so in the worst case, an application might work in testing and then fail in production. If FOR UPDATE
is specified, the cursor is guaranteed to be updatable.
The main reason not to use FOR UPDATE
with WHERE CURRENT OF
is if you need the cursor to be scrollable, or to be isolated from concurrent updates (that is, continue to show the old data). If this is a requirement, pay close heed to the caveats shown above.
The SQL standard only makes provisions for cursors in embedded SQL. The PostgreSQL server does not implement an OPEN
statement for cursors; a cursor is considered to be open when it is declared. However, ECPG, the embedded SQL preprocessor for PostgreSQL, supports the standard SQL cursor conventions, including those involving DECLARE
and OPEN
statements.
The server data structure underlying an open cursor is called a portal. Portal names are exposed in the client protocol: a client can fetch rows directly from an open portal, if it knows the portal name. When creating a cursor with DECLARE
, the portal name is the same as the cursor name.
You can see all available cursors by querying the pg_cursors
system view.
Examples
To declare a cursor:
DECLARE liahona CURSOR FOR SELECT * FROM films;
See FETCH for more examples of cursor usage.
Compatibility
The SQL standard allows cursors only in embedded SQL and in modules. PostgreSQL permits cursors to be used interactively.
According to the SQL standard, changes made to insensitive cursors by UPDATE ... WHERE CURRENT OF
and DELETE ... WHERE CURRENT OF
statements are visible in that same cursor. PostgreSQL treats these statements like all other data changing statements in that they are not visible in insensitive cursors.
Binary cursors are a PostgreSQL extension.