История изменений
Исправление no-such-file, (текущая версия) :
Если в данном случае выбрать не все результаты, к примеру с помощью fetchone, то будет ошибка - есть непрочитанные данные
Не в этом, а в небуферизированном.
Как здесь выгребаются результаты?
Как обычно, получаешь результаты пока не кончатся.
Их СУБД сохраняет предварительно?
Да. Но пока ты их не получил, соединение остаётся в режиме выполнения запроса, т.о. другие запросы ты уже через это же соединение давать не можешь.
каком механизм взаимодействия в этом случае
Механизм взаимодействия с чем? С точки зрения БД разницы никакой нет. Просто буферизированный курсор сам получает все данные неявно. А небуферизированным ты должен явно это сделать. Как вариант ты можешь закрыть курсор, что должно сбросить result set на стороне БД.
Вообще, небуферизированный курсор это очень специфическая вещь, которая тебе вряд ли когда-то понадобится. Разве что ты захочешь сделать какую-то свою хитрую буферизацию. Использовать же небуферизированный курсор просто так, сам по себе — это очень плохая идея.
Исходная версия no-such-file, :
Если в данном случае выбрать не все результаты, к примеру с помощью fetchone, то будет ошибка - есть непрочитанные данные
Не в этом, а в небуферизированном.
Как здесь выгребаются результаты?
Как обычно, получаешь результаты пока не кончатся.
Их СУБД сохраняет предварительно?
Да. Но пока ты их не получил, соединение остаётся в режиме выполнения запроса, т.о. другие запросы ты уже через это же соединение давать не можешь.
каком механизм взаимодействия в этом случае
Механизм взаимодействия с чем? С точки зрения БД разницы никакой нет. Просто буферизированный курсор сам получает все данные неявно. А небуферизированным ты должен явно это сделать.
Вообще, небуферизированный курсор это очень специфическая вещь, которая тебе вряд ли когда-то понадобится. Разве что ты захочешь сделать какую-то свою хитрую буферизацию. Использовать же небуферизированный курсор просто так, сам по себе — это очень плохая идея.