Ребят, обязательно ли в postgresql курсоры создавать и использовать внутри

коммитов, от begin до commit?

да

Нашёл выполнил без транзакции, ошибка "ERROR: DECLARE CURSOR can only be used in transaction blocks"

можно hold но транззакцию это не отммееняет

Ну курсор создаётся внутри транзации, и умирает потом при закрытии транзацкции? А нормально ли будет держать транзацкию несколько минут, для пользователей которые совершают множественные запросы http Пагинацию делают вообще через курсоры?

Если хотите поиметь много проблем, обязательно так и делайте. А вообще, желательно писать качественные запросы и индексы, а не использовать курсоры.

Запрос от пользователя с различными параметрами сортировки. Есть поля, по которым часто меняются данные. Время обновление объекта, и при простом оффсет и лимит, данные меняются местами и путаются Сеньор мой говорит, что курсор решит проблему

Разве? По-моему, он просто весь результат получал и хранил в памяти, нет?

да, но он сохраняет результтат после завршения ттранзакции

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 … 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. https://www.postgresql.org/docs/current/sql-declare.html

Еее, огонь) Понял как делать. Теперь вопрос, почему плохо через курсор делать пагинацию для пользователя лично свой?

Тут надо аккуратнее: удерживая транзакцию(снапшот) дольше некого времени вы можете спровоцировать общее падение производительности сервера. Лично видел стабильно встававший колом сервер при транзации дольше двух минут.

не плохо и не хорошо, hold ттребует памяти, без него выше написал Роман

Вообще, сколько видел пагинаций, там вполне нормальной является ситуация, что данные сдвигаются. Мол, перешел на следующую страницу, а там подтянулись данные с прошлой, потому что кто-то добавил новую запись. Если прям так нужно, может быть стоит посмотреть в сторону кеширования идентификаторов? От задачи, конечно, зависит.

https://use-the-index-luke.com/no-offset вверху есть ссылка на переводы

По ключам не вариант. Инндексы не на всех полях, которые юзер может сортировать + 2 джойна с другими таблицами, на которых тоже может быть сортировка. Сортировка может быть на колонке со статусами, а статусы 3 на 10000 записей, значит нужно ещё отсортировать второй раз, базово по id, например, чтобы не сбивался порядок при обновлении записей. Как я заметил, обновление записи смешает результат к концу, при равных условиях сортировки По этому пропуск и ограничение тут как удобный вариант, и курсор для фиксирования результата и перемещения по нему с начала до конца. И так же от id по лимиту дальше не сработает, ибо перемешение идёт Такие вот дела

>По ключам не вариант. Вариант. Но, в любом случае, если хотите какой-то кэш — ну, сделайте таблицу, сделайте её temporary или unlogged, не знаю, и удаляйте периодически. Не надо пытаться хранить что-то в долгую в курсорах. Курсоры были сделаны чтобы получать результат, который не влез бы в память, нередко полезны ещё в этом качестве — и не очень поддержываются сообществом для чего бы то ни было ещё.

> нужно ещё отсортировать второй раз, базово по id, Ну, отсортируйте, какая вам вообще разница?

плохо что не поддерживаются, удобный механизм

Вообще, temporary таблица лучшэ примерно всем. Но это тожэ очень плохой вариант — поскольку получается, что сэссия пользователя привязана к сэссии постгрес, добиться такой привязки в типичном http — довольно сложно и болезненно.

не лучшше она) лучшше только в реализации Pg(((((

Я не вижу вообще ничего в них хорошэго. 30 лет назад это примерно соответствовало паттэрну работы с базами данных. Сэссии, таблички на мониторах, курсором (pun intended) пользователь их листает... Сейчас общий пейзаж несколько поменялся.

(Посмотрев на названия чятика) Ну да, мы тут вроде не foxbase обсуждаем.

это как измеениился?

Всё через web, сэссии — виртуальные, жывут странное время, плюс их можэт быть много, запросы к апп-серверу — обычно ограничены по времени, вот это всё.

Если нужна пагинация без повторов показанных строк, тогда зафиксируйте id строки, с которой начали показ и дальше limit + offset + where id >= value

В таком подходе проблема в "where id >= value"

Какая?

Какой ещё offset, если там id >= value? Ну, и человек справедливо объяснил — у него не по id отсортировано. И дажэ не по дате (с которой id обычно коррелирует примерно в 1, потому можно искать по id, когда человек хотел дату). Впрочем, в этом случае границами будут поля сортировки, понятно.

да заказикам пофиг на эти рассуждения ))))) отсутствие курсоров вне транзакций это плохо))) но сообщество будет говорить как вы я понимаю

Сортировка то не по id

ммм… почему вы считаете, что они отсутствуют вне транакций?

а как без hold?

нужен WITH HOLD, ну и используйте. в чём проблема?

Дата обновление записи. Увы, раз в секунду обновляется состояние 10 записей, а их тысячи. И клиентская часть хочет выгрузить всë, по страницам. Из-за сети это занимает до 10с

он читает полный датасет

проблема в том зачем курсору транзакция? ))))