Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Tue, 18 Feb 2025 at 09:51, Jelte Fennema-Nio wrote: > Rebased it, and moved some of the new header definitions around to > hopefully not have to rebase again. This required another rebase, but I've decided that I think it'll be most fruitful to continue the discussion on protocol changes in th

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Mon, Aug 26, 2024 at 8:40 AM Robert Haas wrote: > On Fri, Aug 23, 2024 at 3:40 PM Jacob Champion > wrote: > > Agreed on the name. I've attached a reconfigured version of v15-0003, > > with an extension that should hopefully not throw off the cfbot, and a > > commit message that should hopefull

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Fri, Aug 23, 2024 at 3:40 PM Jacob Champion wrote: > Agreed on the name. I've attached a reconfigured version of v15-0003, > with an extension that should hopefully not throw off the cfbot, and a > commit message that should hopefully not misrepresent the discussion > so far? LGTM. Objections?

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Fri, Aug 23, 2024 at 7:42 AM Jelte Fennema-Nio wrote: > > On Fri, 23 Aug 2024 at 16:02, Robert Haas wrote: > > Personally, I'm 100% convinced at this point that we're arguing about > > the wrong problem. Before, I didn't know for sure whether anyone would > > be mad if we redefined PQprotocolV

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Fri, 23 Aug 2024 at 16:02, Robert Haas wrote: > Personally, I'm 100% convinced at this point that we're arguing about > the wrong problem. Before, I didn't know for sure whether anyone would > be mad if we redefined PQprotocolVersion(), but now I know that there > is at least one person who wil

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Wed, Aug 21, 2024 at 3:14 PM Jacob Champion wrote: > Put another way: we've seen that our protocol-version joint has rusted > [1, 2]. I agree that needs to be fixed. But I also believe that we > shouldn't try to smash the joint open with a hammer, and that belief > seems philosophically at odds

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Tue, Aug 20, 2024 at 3:17 PM Jelte Fennema-Nio wrote: > > On Tue, 20 Aug 2024 at 23:48, Jacob Champion > wrote: > > That guarantee (if adopted) would also make it possible for my use > > case to proceed correctly, since a libpq client can still speak 3.0 > > packets on the socket safely. > > N

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Tue, 20 Aug 2024 at 23:48, Jacob Champion wrote: > That guarantee (if adopted) would also make it possible for my use > case to proceed correctly, since a libpq client can still speak 3.0 > packets on the socket safely. Not necessarily (at least not how I defined it). If a protocol parameter h

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Tue, Aug 20, 2024 at 12:55 PM Jelte Fennema-Nio wrote: > Another way of describing this guarantee: If a client connects using > 3.8 and configures no protocol parameters, the client needs to handle > anything 3.8 specific that the handshake requires (such as longer > cancel token). But then aft

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Tue, 20 Aug 2024 at 19:31, Jacob Champion wrote: > It's applicable to the use case I was talking about with Jelte. A > libpq client dropping down to the socket level is relying on > (implicit, currently undocumented/undecided, possibly incorrect!) > intermediary guarantees that the protocol pro

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Tue, 20 Aug 2024 at 19:02, David G. Johnston wrote: > So basically my proposal amounted to making every update a "major version > update" and changing the behavior surrounding NegotiateProtocolVersion so it > applies to major version differences. I'll stand by that change in > definition.

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Tue, Aug 20, 2024 at 10:46 AM Jacob Champion < jacob.champ...@enterprisedb.com> wrote: > On Tue, Aug 20, 2024 at 10:42 AM David G. Johnston > wrote: > > Semantic versioning guidelines are not something we are following, > especially here. > > I understand; the protocol is ours, and we'll do wh

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Tue, Aug 20, 2024 at 10:42 AM David G. Johnston wrote: > Semantic versioning guidelines are not something we are following, especially > here. I understand; the protocol is ours, and we'll do whatever we do in the end. I'm claiming that we can choose to provide semantics, and if we do, those

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Tue, Aug 20, 2024 at 10:31 AM Jacob Champion < jacob.champ...@enterprisedb.com> wrote: > If we decide we can't, then so be it -- things will > break either way -- but it's still strange to me that we'd be okay > with literally zero forward compatibility and still call that a "minor > version".

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Tue, Aug 20, 2024 at 8:24 AM Heikki Linnakangas wrote: > > Put another way: for a middlebox on the connection (which may be > > passively observing, but also maybe actively adding new messages to > > the stream), what is guaranteed to remain the same in the protocol > > across a minor version b

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Tue, Aug 20, 2024 at 10:03 AM Jacob Champion < jacob.champ...@enterprisedb.com> wrote: > On Tue, Aug 20, 2024 at 7:26 AM Jelte Fennema-Nio > wrote: > > In practical terms I think that means for a minor version bump the > > format of the StartupMessage cannot be changed. Changing anything else

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Tue, Aug 20, 2024 at 1:02 PM David G. Johnston wrote: > So basically my proposal amounted to making every update a "major version > update" and changing the behavior surrounding NegotiateProtocolVersion so it > applies to major version differences. I'll stand by that change in > definition.

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Tue, Aug 20, 2024 at 7:26 AM Jelte Fennema-Nio wrote: > In practical terms I think that means for a minor version bump the > format of the StartupMessage cannot be changed. Changing anything else > is fair game for a minor protocol version bump. I may be in a tiny minority here, but when I com

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Tue, Aug 20, 2024 at 9:44 AM Robert Haas wrote: > On Tue, Aug 20, 2024 at 12:42 PM David G. Johnston > wrote: > > I'm wondering why we are indicating that minor versions of the protocol > are even a real thing. > > Because that concept is already a part of the existing wire protocol. > > Righ

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Tue, 20 Aug 2024 at 18:42, David G. Johnston wrote: > v18 libpq-based clients, if they attempt to connect using v4 and fail, will > try again using the v3 connection. That will retain status quo behavior when > something like a connection pooler doesn't understand the new reality. Having co

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Tue, Aug 20, 2024 at 12:42 PM David G. Johnston wrote: > I'm wondering why we are indicating that minor versions of the protocol are > even a real thing. Because that concept is already a part of the existing wire protocol. -- Robert Haas EDB: http://www.enterprisedb.com

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Tue, Aug 20, 2024 at 9:02 AM Robert Haas wrote: > Yes. And the major * 1 + minor convention is used in other places > already, for PG versions, so it might already be familiar to some > people. > I'm wondering why we are indicating that minor versions of the protocol are even a real thing

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Tue, Aug 20, 2024 at 11:53 AM Jelte Fennema-Nio wrote: > On Tue, 20 Aug 2024 at 17:46, Robert Haas wrote: > > I personally like this less than both (a) adding a new function and > > (b) redefining the existing function as Jelte proposes. It just seems > > too clever to me. > > Agreed, I'm not

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Tue, 20 Aug 2024 at 17:46, Robert Haas wrote: > I personally like this less than both (a) adding a new function and > (b) redefining the existing function as Jelte proposes. It just seems > too clever to me. Agreed, I'm not really seeing a benefit of returning 4 instead of 30004. Both are new

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Tue, Aug 20, 2024 at 11:24 AM Heikki Linnakangas wrote: > That's not a completely crazy idea, it crossed my mind too. And since we > already decided to skip protocol number 3.1, how about we jump directly > to 3.4. That way: > > protocol | > version | PQProtocolVersion() > > 2 | 2 (

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On 20/08/2024 16:48, Jacob Champion wrote: On Mon, Aug 19, 2024 at 1:54 PM Jelte Fennema-Nio wrote: My point is that the code that breaks, actually wants to be broken in this case. I'll turn this around then and assume for a moment that this is true: no matter what the use cases are, they all

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Tue, 20 Aug 2024 at 15:48, Jacob Champion wrote: > Put another way: for a middlebox on the connection (which may be > passively observing, but also maybe actively adding new messages to > the stream), what is guaranteed to remain the same in the protocol > across a minor version bump? Hopefully

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Mon, Aug 19, 2024 at 1:54 PM Jelte Fennema-Nio wrote: > My point is that the code that breaks, actually wants to be broken in this > case. I'll turn this around then and assume for a moment that this is true: no matter what the use cases are, they all want to be broken for correctness. If thi

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Mon, 19 Aug 2024 at 16:16, Robert Haas wrote: > If somebody is using PQprotocolVersion() to detect the arrival of a > new protocol version, it stands to reason that they only care about > new major protocol versions, because that's what the function is > defined to tell you about. Anyone who ha

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Mon, Aug 19, 2024 at 3:30 AM Jelte Fennema-Nio wrote: > But **now I actually feel much more strongly about reusing the same > function**. Because by introducing a new function we actually break > the users of the second use-case. > > P.S. The docs for PQprotocolVersion[1] have never said that t

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Mon, 19 Aug 2024 at 05:44, Robert Haas wrote: > I feel like what you're really complaining about here is that libpq is > not properly versioned. We've just been calling it libpq.so.5 forever > instead of bumping the version number when we change stuff. There is PQlibVersion() that can be used

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

Robert Haas writes: > I feel like what you're really complaining about here is that libpq is > not properly versioned. We've just been calling it libpq.so.5 forever > instead of bumping the version number when we change stuff. Maybe we > should start doing that, because that's exactly what version

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Sat, Aug 17, 2024 at 5:32 AM Jelte Fennema-Nio wrote: > Not introducing new APIs definitely is useful to clients and the > community. Before users can use a new API, their libpq wrapper needs > to expose this new function that calls it through FFI. First of all > this requires work from client

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Fri, 16 Aug 2024 at 19:44, Jacob Champion wrote: > Keeping in mind that I'm responding to the change from 3 to 3: Let me start with the fact that I agree we **shouldn't** change 3 to 3. And the proposed patch also specifically doesn't. > https://github.com/search?q=PQprotocolVersi

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Fri, Aug 16, 2024 at 4:03 PM Dave Cramer wrote: > Admittedly I'm a bit late into this discussion so I may be off base. > Ultimately we need to negotiate the protocol. From what I can tell for libpq > we are providing a function that returns a number, currently 3. > > The proposal is to change

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Fri, 16 Aug 2024 at 15:54, Heikki Linnakangas wrote: > On 16/08/2024 22:45, Dave Cramer wrote: > > On Fri, 16 Aug 2024 at 15:26, Heikki Linnakangas > > wrote: > > > > On 16/08/2024 21:01, Robert Haas wrote: > > > On Fri, Aug 16, 2024 at 1:44 PM Jacob Champion

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On 16/08/2024 22:45, Dave Cramer wrote: On Fri, 16 Aug 2024 at 15:26, Heikki Linnakangas > wrote: On 16/08/2024 21:01, Robert Haas wrote: > On Fri, Aug 16, 2024 at 1:44 PM Jacob Champion > mailto:jacob.champ...@enterprisedb.com>> wrote: >> https://

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Fri, 16 Aug 2024 at 15:26, Heikki Linnakangas wrote: > On 16/08/2024 21:01, Robert Haas wrote: > > On Fri, Aug 16, 2024 at 1:44 PM Jacob Champion > > wrote: > >> > https://github.com/psycopg/psycopg2/blob/658afe4cd90d3e167d7c98d22824a8d6ec895b1c/tests/test_async.py#L89 > >> > https://github.c

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On 16/08/2024 21:01, Robert Haas wrote: On Fri, Aug 16, 2024 at 1:44 PM Jacob Champion wrote: https://github.com/psycopg/psycopg2/blob/658afe4cd90d3e167d7c98d22824a8d6ec895b1c/tests/test_async.py#L89 https://github.com/infusion/PHP/blob/7ebefb6426bb4b4820a30cca5c3a10bfd757b6ea/ext/p

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Fri, Aug 16, 2024 at 1:44 PM Jacob Champion wrote: > > https://github.com/psycopg/psycopg2/blob/658afe4cd90d3e167d7c98d22824a8d6ec895b1c/tests/test_async.py#L89 > > https://github.com/infusion/PHP/blob/7ebefb6426bb4b4820a30cca5c3a10bfd757b6ea/ext/pgsql/pgsql.c#L864 IMHO these example

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Fri, Aug 16, 2024 at 12:05 AM Jelte Fennema-Nio wrote: > > On Fri, 16 Aug 2024 at 00:39, Jacob Champion > wrote: > > > > On Thu, Aug 15, 2024 at 3:04 PM Heikki Linnakangas wrote: > > > Perhaps we should even change it to return > > > 30 for protocol version 3.0, and just leave a note in t

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Fri, Aug 16, 2024 at 10:51 AM Heikki Linnakangas wrote: > Now, I think we should still do it, but it might not warrant changing > the default. Unfortunately that means that it will get very little > adoption. It will only be adopted as a side-effect of some other changes > that make people chan

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Fri, 16 Aug 2024 at 16:51, Heikki Linnakangas wrote: > That said, I think we *should* change the default for the time being, so > that developers working on the bleeding edge and building from git get > some exposure to it. Hopefully that will nudge some of the poolers to > adopt NegotiateProto

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On 16/08/2024 15:55, Robert Haas wrote: On Thu, Aug 15, 2024 at 6:03 PM Heikki Linnakangas wrote: On the default for "max_protocol_version": I'm pretty disappointed if we cannot change the default to "latest". I realize that that won't work with poolers that don't implement NegotiateProtocolVer

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Thu, Aug 15, 2024 at 6:03 PM Heikki Linnakangas wrote: > On the default for "max_protocol_version": I'm pretty disappointed if we > cannot change the default to "latest". I realize that that won't work > with poolers that don't implement NegotiateProtocolVersion. But I'm > afraid if we make the

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Fri, 16 Aug 2024 at 00:39, Jacob Champion wrote: > > On Thu, Aug 15, 2024 at 3:04 PM Heikki Linnakangas wrote: > > Perhaps we should even change it to return > > 30 for protocol version 3.0, and just leave a note in the docs like > > "in older versions of libpq, this returned 3 for protoco

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Thu, Aug 15, 2024 at 3:04 PM Heikki Linnakangas wrote: > Perhaps we should even change it to return > 30 for protocol version 3.0, and just leave a note in the docs like > "in older versions of libpq, this returned 3 for protocol version 3.0". I think that would absolutely break current co

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On 14/08/2024 21:04, Jelte Fennema-Nio wrote: On Wed, 7 Aug 2024 at 22:10, Robert Haas wrote: I respect that, but I don't want to get flamed for doing something that might be controversial without anybody else endorsing it. I'll commit this if it gets some support, but not otherwise. I'm willin

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Wed, Aug 14, 2024 at 2:04 PM Jelte Fennema-Nio wrote: > Applied all 0002 feedback. Although I used Min(proto, > PG_PROTOCOL_LATEST) because Max results in the wrong value. Picky, picky. :-) Committed. > Makes sense. I'm not in too much of a hurry with this specific one. So > I'll leave it li

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Mon, Jun 24, 2024 at 9:19 AM Jelte Fennema-Nio wrote: > > I agree with 0002 except for the change from PG_PROTOCOL_MINOR(proto) > > > PG_PROTOCOL_MINOR(PG_PROTOCOL_LATEST) to proto > PG_PROTOCOL_LATEST. > > I prefer that test the way it is; I think the intent is clearer with > > the existing co

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Mon, Jun 24, 2024 at 9:19 AM Jelte Fennema-Nio wrote: > > > Patch 3: Similar to 1 & 2 in that it has no actual effect yet. But > > > after bumping the version this would be a user visible API change, so > > > I expect it requires a bit more discussion. > > > > I don't know if this is the right

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Wed, Jun 5, 2024 at 10:06 AM Jelte Fennema-Nio wrote: > Patch 1 & 2: Minor code changes with zero effect until we actually > bump the protocol version or add protocol parameters. I hope these can > be merged rather soon to reduce the number of patches in the patchset. 0001 looks like a bug fix

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Thu, Jun 6, 2024 at 3:27 PM Jelte Fennema-Nio wrote: > Of course there's always the possibility to review more. But I don't > really agree with this summary of my review activity. Nonetheless, I need to take a break from this to work on some of my own stuff. I'll circle back around to it. --

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Thu, 6 Jun 2024 at 18:01, Robert Haas wrote: > As I see it, the issue here is whether the default value would ever be > different from the latest value. If not, then using blank to mean the > latest seems fine, but if so, then I'd expect blank to mean the > default version and latest to mean th

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Thu, Jun 6, 2024 at 5:12 AM Jelte Fennema-Nio wrote: > Looking at ssl_max_protocol_version closer though, to stay really > consistent I'd have to change "latest" to be renamed to empty string > (i.e. there is no max_protocol_version). I think I might prefer > staying consistent over introducing

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Thu, 6 Jun 2024 at 03:03, Robert Haas wrote: > This makes some sense to me. I don't think that I believe > max_protocol_version=latest is future-proof: just because I want to > opt into this round of new features doesn't mean I feel the same way > about the next round. But it may still be a goo

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Wed, Jun 5, 2024 at 9:03 PM Robert Haas wrote: > It's a funny use of "max" and "min", because the max is really what we're > trying to do and the min is what we end > up with, and those terms don't necessarily bring those ideas to mind. requested_protocol_version and minimum_protocol_versio

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Wed, Jun 5, 2024 at 5:16 PM Jelte Fennema-Nio wrote: > I agree longcancelkey=true is not what we want. In my patch 0004, you > can specify max_protocol_version=latest to use the latest protocol > version as opt-in. This is a future proof version of > protocolversion=3.1 that you're proposing, b

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Wed, 5 Jun 2024 at 22:48, Robert Haas wrote: > I agree that we need such a mechanism, but if the driving feature is > cancel-key length, I expect that opt-in isn't going to work very well. > Opt-in seems like it would work well with compression or transparent > column encryption, but few users

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Wed, Jun 5, 2024 at 1:50 PM Jelte Fennema-Nio wrote: > Totally agreed, and that's easily achievable because of the > NegotiateProtocolVersion message. We're all good on v18 to v17 > connections and protocol changes, as long as we make any new behaviour > depend on either a protocol parameter or

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Wed, 5 Jun 2024 at 17:12, Robert Haas wrote: > Well, hang on. The discussion on that thread suggests that this is > only going to break connections to servers that don't have > NegotiateProtocolVersion. Yes, correct. > What > I really don't want is for v18 to break connections to v17 servers.

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Wed, Jun 5, 2024 at 10:06 AM Jelte Fennema-Nio wrote: > FYI Heikki his patchset is here: > https://www.postgresql.org/message-id/flat/508d0505-8b7a-4864-a681-e7e5edfe32aa%40iki.fi > > Afaict there's no way to implement this with old clients supporting > the new message. So it would need to be o

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Sat, May 25, 2024 at 6:40 AM Jelte Fennema-Nio wrote: > Of the proposed changes so far on the mailing list the only 2 that > would fall under 1 imho are: > 1. The ParameterSet message > 2. Longer than 32bit secret in BackendKeyData Yeah. I wonder how Heikki thinks he can do (2) without breakin

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Fri, May 24, 2024 at 6:09 PM Jelte Fennema-Nio wrote: > Separating it from the GUC infrastructure will mean we need to > duplicate a lot of the infrastructure. Assuming we don't care about > SHOW or pg_settings (which I agree are not super important), the > things that we would want for protoco

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Sat, 25 May 2024 at 06:40, Jelte Fennema-Nio wrote: > On Thu, 23 May 2024 at 20:12, Tom Lane wrote: > > > > Jelte Fennema-Nio writes: > > > On Fri, 17 May 2024 at 21:24, Robert Haas > wrote: > > >> Perhaps these are all minority positions, but I can't tell you what > > >> everyone thinks, o

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

(pressed send to early) On Sat, 25 May 2024 at 12:39, Jelte Fennema-Nio wrote: > But again if I'm alone in this, then I don't ... mind budging on this to move this decision along. Using _pq_.xxx parameters for all protocol changes would totally be acceptable to me.

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Thu, 23 May 2024 at 20:12, Tom Lane wrote: > > Jelte Fennema-Nio writes: > > On Fri, 17 May 2024 at 21:24, Robert Haas wrote: > >> Perhaps these are all minority positions, but I can't tell you what > >> everyone thinks, only what I think. > > > I'd love to hear some opinions from others on t

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Thu, 23 May 2024 at 20:40, Tom Lane wrote: > > Jacob Champion writes: > > Would it be good to expand on that idea of criticality? IIRC one of > > Jelte's complaints earlier was that middleware has to know all the > > extension types anyway, to be able to figure out whether it has to do > > som

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Fri, 24 May 2024 at 15:28, Robert Haas wrote: > > On Thu, May 23, 2024 at 4:00 PM Tom Lane wrote: > > I don't recall exactly what I thought earlier, but now I think we'd > > be better off with separate infrastructure. guc.c is unduly complex > > already. Perhaps there are bits of it that cou

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Thu, May 23, 2024 at 4:00 PM Tom Lane wrote: > I don't recall exactly what I thought earlier, but now I think we'd > be better off with separate infrastructure. guc.c is unduly complex > already. Perhaps there are bits of it that could be factored out > and shared, but I bet not a lot. OK. T

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

Robert Haas writes: > I think part of the reason we ended up with the protocol parameters = > GUCs thing is because you seemed to be concurring with that approach > upthread. I think it was Jelte's idea originally, but I interpreted > some of your earlier remarks to be supporting it. I'm not sure

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Thu, May 23, 2024 at 2:12 PM Tom Lane wrote: > I got around to looking through this thread in preparation for next > week's patch review session. I have a couple of opinions to offer: I agree with these opinions. Independently of that, I'm glad you shared them. I think part of the reason we

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

Jacob Champion writes: > Would it be good to expand on that idea of criticality? IIRC one of > Jelte's complaints earlier was that middleware has to know all the > extension types anyway, to be able to figure out whether it has to do > something about them or not. HTTP has the concept of hop-by-ho

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Thu, May 23, 2024 at 11:12 AM Tom Lane wrote: > If a reader doesn't recognize a particular > chunk code, it can still tell whether the chunk is "critical" or not, > and thereby decide if it must give up or can proceed while ignoring > that chunk.) Would it be good to expand on that idea of cri

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

Jelte Fennema-Nio writes: > On Fri, 17 May 2024 at 21:24, Robert Haas wrote: >> Perhaps these are all minority positions, but I can't tell you what >> everyone thinks, only what I think. > I'd love to hear some opinions from others on these design choices. So > far it seems like we're the only t

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Fri, 17 May 2024 at 21:24, Robert Haas wrote: > I think the > fear that we're going to run into cases where such complex handshaking > is necessary is a major reason why I'm afraid of Jelte's ideas about > ParameterSet: it seems much more opinionated to me than he seems to > think it is. I thi

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Fri, May 17, 2024 at 1:26 PM Jacob Burroughs wrote: > I was leaving the details around triggering that for this conversation > and in that patch just designing the messages in a way that would > allow adding the reconfiguration/restarting to be easily added in a > backwards-compatible way in a

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Fri, May 17, 2024 at 3:15 AM Robert Haas wrote: > > OK, so you made it so that compressed data is fully self-identifying. > Hence, there's no need to worry if something gets changed: the > receiver, if properly implemented, can't help but notice. The only > downside that I can see to this desig

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Thu, May 16, 2024 at 1:39 PM Jacob Burroughs wrote: > As currently implemented [1], the client sends the server the list of > all compression algorithms it is willing to accept, and the server can > use one of them. If the server knows what `_pq_.compression` means > but doesn't actually suppo

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Thu, 16 May 2024 at 18:57, Robert Haas wrote: > Ugh, it's so hard to communicate clearly about this stuff. I didn't > really have any thought that we'd ever try to handle something as > complicated as compression using ParameterSet. Okay, then it's definitely very hard to communicate clearly a

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Thu, May 16, 2024 at 6:57 AM Robert Haas wrote: > > Ugh, it's so hard to communicate clearly about this stuff. I didn't > really have any thought that we'd ever try to handle something as > complicated as compression using ParameterSet. I tend to agree that > for compression I'd like to see the

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Thu, May 16, 2024 at 12:09 PM Jelte Fennema-Nio wrote: > I don't really understand the benefit of your proposal over option 2 > that I proposed. Afaict you're proposing that for e.g. compression we > first set _pq_.supports_compression=1 in the StartupMessage and use > that to do feature detec

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Thu, 16 May 2024 at 17:29, Robert Haas wrote: > You're probably not going to like this answer, but I feel like this is > another sign that you're trying to use the protocol extensibility > facilities in the wrong way. In my first reply to the thread, I > proposed having the client send _pq_.pro

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Thu, May 16, 2024 at 5:22 AM Jelte Fennema-Nio wrote: > If we're not setting the protocol parameter in the StartupMessage, > there's currently no way for us to know if the protocol parameter is > supported by the server. If protocol parameters were unchangable then > that would be fine, but the

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Fri, 5 Apr 2024 at 18:30, Dave Cramer wrote: > On Fri, 5 Apr 2024 at 12:09, Jelte Fennema-Nio wrote: >> I'll take a look at redesigning the protocol parameter stuff. To work >> with dedicated functions instead. > > +1 It's been a while, but I now actually took the time to look into this. And

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Tue, 23 Apr 2024 at 19:39, Jacob Champion wrote: > > On Mon, Apr 22, 2024 at 2:20 PM Jelte Fennema-Nio wrote: > > 1. I strongly believe minor protocol version bumps after the initial > > 3.1 one can be made painless for clients/poolers (so the ones to > > 3.2/3.3/etc). Similar to how TLS 1.3 c

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Tue, 23 Apr 2024 at 17:03, Robert Haas wrote: > If a client doesn't know about encrypted columns and sets that > bit at random, that will break things, and formally I think that's a > risk, because I don't believe we document anywhere that you shouldn't > set unused bits in the format mask. But

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Mon, Apr 22, 2024 at 2:20 PM Jelte Fennema-Nio wrote: > 1. I strongly believe minor protocol version bumps after the initial > 3.1 one can be made painless for clients/poolers (so the ones to > 3.2/3.3/etc). Similar to how TLS 1.3 can be safely introduced, and not > having to worry about breaki

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Mon, Apr 22, 2024 at 5:19 PM Jelte Fennema-Nio wrote: > On Mon, 22 Apr 2024 at 16:26, Robert Haas wrote: > > That's a fair point, but I'm still not seeing much practical > > advantage. It's unlikely that a client is going to set a random bit in > > a format parameter for no reason. > > I think

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Mon, 22 Apr 2024 at 16:26, Robert Haas wrote: > That's a fair point, but I'm still not seeing much practical > advantage. It's unlikely that a client is going to set a random bit in > a format parameter for no reason. I think you're missing an important point of mine here. The client wouldn't

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Thu, Apr 18, 2024 at 5:36 PM Jelte Fennema-Nio wrote: > To clarify: My proposed approach is to use a protocol extension > parameter for to enable the new messages that the server can send > (like Peter is doing now). And **in addition to that** gate the new > Bind format type behind a feature s

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Thu, 18 Apr 2024 at 23:36, Jelte Fennema-Nio wrote: > To clarify: My proposed approach is to use a protocol extension > parameter for to enable the new messages that the server can send > (like Peter is doing now). And **in addition to that** gate the new > Bind format type behind a feature swi

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Thu, 18 Apr 2024 at 22:17, Robert Haas wrote: > If we go with Peter's approach, every driver that supports his feature > will work perfectly, and every driver that doesn't will work exactly > as it does today. The risk of breaking anything is as near to zero as > human developers can reasonably

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Thu, Apr 18, 2024 at 3:34 PM Jelte Fennema-Nio wrote: > I really don't understand what exactly you're worried about. What do > you expect will break when bumping the protocol version? As Dave said, > clients should never bail out due to protocol version differences. Sure, and I should never fo

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Mon, 15 Apr 2024 at 21:47, Dave Cramer wrote: >> On Mon, 15 Apr 2024 at 19:52, Robert Haas wrote: >> > surely it can't be right to use protocol >> > version 3.0 to refer to a bunch of different things. But at the same >> > time, surely we don't want clients to start panicking and bailing out >

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Mon, 15 Apr 2024 at 15:38, Jelte Fennema-Nio wrote: > On Mon, 15 Apr 2024 at 19:43, Robert Haas wrote: > > > > On Sat, Apr 6, 2024 at 6:14 PM Jelte Fennema-Nio wrote: > > > I think for clients/drivers, the work would generally be pretty > > > minimal. For almost all proposed changes, clients

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Mon, 15 Apr 2024 at 19:43, Robert Haas wrote: > > On Sat, Apr 6, 2024 at 6:14 PM Jelte Fennema-Nio wrote: > > I think for clients/drivers, the work would generally be pretty > > minimal. For almost all proposed changes, clients can "support" the > > protocol version update by simply not using

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

[ Hit send too early, sorry. ] On Mon, Apr 15, 2024 at 1:43 PM Robert Haas wrote: > But the wire protocol changes very slowly, and I think that is a > difference that actually matters quite a bit here. Broadly speaking, I > can use a psq ...a psql that I just built today to talk to a server from

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Sat, Apr 6, 2024 at 6:14 PM Jelte Fennema-Nio wrote: > I think for clients/drivers, the work would generally be pretty > minimal. For almost all proposed changes, clients can "support" the > protocol version update by simply not using the new features, ... I mean, I agree if a particular proto

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On 05.04.24 14:55, Robert Haas wrote: I also wonder how the protocol negotiation for column encryption is actually going to work. What are the actual wire protocol changes that are needed? What does the server need to know from the client, or the client from the server, about what is supported?

  1   2   >