Thank you @austindrenski! I am planning to look at submitting this back. It does make sense that I don't have to install all tested versions of PostgreSQL locally, that's good!

To @klimchuk and anybody that wants to use this now, if I may I'd like to point out that Npgsql cursor dereferencing is available and working in a reboot of Massive that I've been working on and using for a couple of years, and just released into the wild.

In terms of features to potentially submit back:

The fact that PostgreSQL cursors clearly aren't at all efficient for FETCHing large streams of data in a single FETCH I think means that having a configurable FETCH size is a good idea; as I've done in Mighty, and as opposed to always doing FETCH ALL in the Npgsql v2 support.
In Mighty, I've also written code to add an automatic wrapping transaction when needed, for cursor dereferencing
- It activiates if there are any non-input cursor parameters on a query command;
- But it re-uses the existing transaction on DbConnection (or TransactionScope) if there is one, and only creates a new wrapping transaction otherwise

If I may, I'd very much like to recommend that idea as something that would be reasonable here, too. (People using the driver just want it to work, and that definitely helps!)

EDIT: For now, in the PR I made below, I changed my mind about the second of my two suggestions here, because automatically wrapping with a transaction doesn't fit with the way that, as I understand it, Npgsql tries to keep people aware of what they're doing - especially rather than silently doing expensive things. Even though I guess that not creating the transaction for the user when needed still requires an additional change to client code that might have worked on another DB?

Consider bringing back automatic dereferencing of cursors #1785

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions