Let me start with this: I agree with you that both HOLD and GoAway
would work well as protocol extensions. And if that's what is needed
to get stuff to continue moving in the protocol space, then fine
that's what I'll do... But I have some reasons to prefer a protocol
version bump at least for GoAw
[I considered splitting this off into a new thread, but I think Dave
has to wait for it to be resolved before much can happen with the
patch. Sorry Dave.]
On Wed, Dec 10, 2025 at 3:01 PM Jelte Fennema-Nio wrote:
> If we keep the features that are bundled with a protocol version bump
> of the kind
On Wed, 10 Dec 2025 at 18:41, Jacob Champion
wrote:
> I think it'd be helpful for proposals to describe why a minor version
> bump was chosen over a protocol extension parameter (or vice versa),
> so that we can begin to develop some consensus.
Agreed.
> With the
> minor-version strategy, if we
On Mon, Dec 8, 2025 at 1:43 PM Jelte Fennema-Nio wrote:
> 1. We still have fairly limited experience with protocol options, so
> afaik not everyone agrees what we should use a version bump for vs a
> protocol extension.
I think it'd be helpful for proposals to describe why a minor version
bump wa
On Mon, 8 Dec 2025 at 23:08, Dave Cramer wrote:
> Thx for the comments.
One more comment: It would be good to enable tracing[1][2] for your
test, especially because I think you still need to update the tracing
logic in libpq for your new packet type.
[1]:
https://github.com/postgres/postgres/bl
On Mon, Dec 8, 2025 at 4:43 PM Jelte Fennema-Nio wrote:
> On Sun, 7 Dec 2025 at 15:38, Dave Cramer wrote:
> > My main driver here is to allow the creation of Holdable portals at the
> protocol level for drivers.
>
> Overall seems like a sensible feature to want. A somewhat random
> collection of
On Sun, 7 Dec 2025 at 15:38, Dave Cramer wrote:
> My main driver here is to allow the creation of Holdable portals at the
> protocol level for drivers.
Overall seems like a sensible feature to want. A somewhat random
collection of thoughts:
1. We still have fairly limited experience with protoc
Hi,
I did not look into this patch in detail yet, but I am +1 for being
able to create cursors at the protocol level.
I think this should be allowed for regular cursors as well. One
big use-case I see is allowing postgres_fdw to create and fetch
from cursors at the protocol level rather than SQL
Greetings,
My main driver here is to allow the creation of Holdable portals at the
protocol level for drivers. Currently the only way to create a holdable
cursor is at the SQL level.
DECLARE liahona CURSOR WITH HOLD FOR SELECT * FROM films;
The JDBC driver has an option in the API to have resul
