Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vd5xD-00Dshk-0j for pgsql-hackers@arkaria.postgresql.org; Tue, 06 Jan 2026 12:14:28 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vd5xB-007jwZ-2H for pgsql-hackers@arkaria.postgresql.org; Tue, 06 Jan 2026 12:14:26 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vd5xB-007jwR-0I for pgsql-hackers@lists.postgresql.org; Tue, 06 Jan 2026 12:14:25 +0000 Received: from mail-yx1-xb12d.google.com ([2607:f8b0:4864:20::b12d]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vd5xA-004VVa-0S for pgsql-hackers@lists.postgresql.org; Tue, 06 Jan 2026 12:14:24 +0000 Received: by mail-yx1-xb12d.google.com with SMTP id 956f58d0204a3-64455a2a096so732535d50.3 for ; Tue, 06 Jan 2026 04:14:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767701663; x=1768306463; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=mF5aZspgvyAgqpoNVWXIMgA/YJzLKrmoM5fronsdumY=; b=I2qaoTIDalAIgl5RT7STvvO6Rv8SrEHviIfydJYxt7eCyeqskniHGQ5xLaopotrqS4 LK+XL+bipEY/mrnM0DMQkSBj77bRG8NnD2T2pH19JoUOUIqjLZt/lrDXKRBPiqb8RqMQ doIDoNlRZrL+5tBVuKjw1MedILF4mENo6AGHd/llku/RWVl/RcAXQ7K7MPK8RxAIiFuk 5Cls5VWpsmEcxC65+vFSYp8OA39tKuNB6HVkQS4+9TNSLrODkEVP/JJgx6ZIor5jt2LJ 36NwyKPGWsUkKG36ilOQwYLDZresVQU64DUIRt4p0op4HOmGXBt3brCeWa86xnKvv/WQ gjfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767701663; x=1768306463; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=mF5aZspgvyAgqpoNVWXIMgA/YJzLKrmoM5fronsdumY=; b=ZXJPdYCGSireJm6gmnaSHqJjrAY+i23tershCTyvqQstmdhd6uphIIMm6yVjlOQsDU qKJaRxosAyLBZzhSfp6jN1wK2cvtHz1xUHbDpKsSFnHXJ2+ollekazXOkRVk9k3wRlt7 Zy8Wb0ysm5+qc6/RbyCbmaXyPT3ynY0os9kOqLtabACRhAorh5gHj7CZAdxE74SzFdTH KVjGaS7Zkhd/3JuXhuYYcKBtOdKDadwLYUf8smPjiuJ58Di0h9wH/wt5esVbbN5emeCY nnqhsEXETuQKv5hcEXsc18xbTcaFsTMX7UhrdiphJjciVI3icCSryQmraWnt+TLXye// TSQQ== X-Forwarded-Encrypted: i=1; AJvYcCWbuNT9ikGz+p1wPCtZiRl/W2kNm/07Y7vDVVv1eBLYqyLipHPyn3Z5qHtTzr06Lcbu9l2eQaEQ/Lx0fNn1@lists.postgresql.org X-Gm-Message-State: AOJu0YzXSOFWDRacDdN/qj8VAoWCv/FptdDDjpEucCuD1eCoXkVEq62C YocX0ML0Jn3MGDFLV+UKw67dnS1Snm9Xd7mrkwD8I+vmLHvGZOJ2dc53jqdTuNehCFIEoASnLbF ND1Orb+NRr3EHyfnHkrpFV9SamjD8kxs= X-Gm-Gg: AY/fxX7hpHAPLlhjnuFBpqZbK2sfUxENjpgY+LGCw3xk+gHRWPGcRw2x0XgRPgKDxo3 1DPKkhzg0qgXQVyy2B5dhYylRh+KSeKuYgjgJsy6kLPxq/kDmIv0+KV8vd31qmarrhbjJph9IUd owWbAULGwkbN+aj0jEmM7b8iUSlPRbOfT8E5R0s6xWAZV90eLD4ZnSiAcpSt5SQTLejkwoYpxWC F57zgHIXzi6RljVyqwMH6BjoYUbc7phTnf+4KuwSd0fxkNHtcT0+7dx22eBW0B0eFdDFg== X-Google-Smtp-Source: AGHT+IGvuKBHwBMpQHXK9+nIr9HbK7gD86Pjfvv3gR8RJ07eTcMrNwfedaILDq9dM6BHqLRYQA0FCdnxuDVhdgMLQAM= X-Received: by 2002:a05:690c:4b85:b0:789:3f0f:ac6a with SMTP id 00721157ae682-790a8a5407bmr51362127b3.16.1767701662889; Tue, 06 Jan 2026 04:14:22 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dave Cramer Date: Tue, 6 Jan 2026 07:14:06 -0500 X-Gm-Features: AQt7F2rrud-Sqq3ZXReOAykNbnpaWLi7uUK2CV4uwG9SEbodvbSAX7AI2A9l0fo Message-ID: Subject: Re: Proposal to allow setting cursor options on Portals To: Jelte Fennema-Nio Cc: Jacob Champion , PostgreSQL Hackers , Heikki Linnakangas Content-Type: multipart/alternative; boundary="000000000000af7a2b0647b71d42" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000af7a2b0647b71d42 Content-Type: text/plain; charset="UTF-8" On Mon, 15 Dec 2025 at 06:32, Dave Cramer wrote: > > > On Sun, 14 Dec 2025 at 09:04, Jelte Fennema-Nio > wrote: > >> On Sun, 14 Dec 2025 at 14:49, Dave Cramer wrote: >> > Here I was thinking that binary was the one that did make sense. The >> pgjdbc driver would like the results back in binary, I believe others would >> as well. >> >> I agree drivers would like binary results back, but it's unclear to me >> how CURSOR_OPT_BINARY is different from setting the result column >> format codes to an array of a single 1? That should also change all >> columns to be binary right? >> > > Fair point. > >> >> > Fair, but from my POV, we are only concerned with Postgres. I would say >> it's up to the other implementations to deal with incompatibilities. >> >> I get what you mean, but I feel like we should at least be concerned >> with popular ecosystem tools like, pgbouncer and pgpool. But then it >> quickly becomes an exercise in where we draw the line, what about >> postgres forks like Yugabyte? Or things very similar like cockroachdb. >> Both of those are distributed, and probably don't use our LSNs. So as >> a concrete example, if we add LSNs to the protocol, it would be nice >> to work with their version too if it's not too much effort. e.g. by >> specifing a length for the commit id in the protocol instead of >> forcing it at the protocol level to always be a 64bit integer. >> > > It would make sense to be forward looking here in the event that Postgres > ever has wider LSN's agreed. > Any progress on this ? Dave > --000000000000af7a2b0647b71d42 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On M= on, 15 Dec 2025 at 06:32, Dave Cramer <davecramer@gmail.com> wrote:


On Sun, 14 Dec 2025 at 09:04, Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
On Sun, 14 Dec 2025 at = 14:49, Dave Cramer <davecramer@gmail.com> wrote:
> Here I was thinking that binary was the one that did make sense. The p= gjdbc driver would like the results back in binary, I believe others would = as well.

I agree drivers would like binary results back, but it's unclear to me<= br> how CURSOR_OPT_BINARY is different from setting the result column
format codes to an array of a single 1? That should also change all
columns to be binary right?

Fair point.= =C2=A0

> Fair, but from my POV, we are only concerned with Postgres. I would sa= y it's up to the other implementations to deal with incompatibilities.<= br>
I get what you mean, but I feel like we should at least be concerned
with popular ecosystem tools like, pgbouncer and pgpool. But then it
quickly becomes an exercise in where we draw the line, what about
postgres forks like Yugabyte? Or things very similar like cockroachdb.
Both of those are distributed, and probably don't use our LSNs. So as a concrete example, if we add LSNs to the protocol, it would be nice
to work with their version too if it's not too much effort. e.g. by
specifing a length for the commit id in the protocol instead of
forcing it at the protocol level to always be a 64bit integer.

It would make sense to be forward looking here in t= he event that Postgres ever has wider LSN's=C2=A0agreed.

Any progress on this ?

Dave
--000000000000af7a2b0647b71d42--