From: | Jacob Champion <jchampion(at)timescale(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Jelte Fennema <me(at)jeltef(dot)nl>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net> |
Subject: | Re: [PATCH] Align GSS and TLS error handling in PQconnectPoll() |
Date: | 2023-02-17 17:01:43 |
Message-ID: | CAAWbhmixS=QagV6NgCSj4DJrWosETr8T5o+H2+f3cBdTfMwc9g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Feb 16, 2023 at 10:59 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> I am adding Stephen Frost
> in CC to see if he has any comments about all this part of the logic
> with gssencmode.
Sounds good.
> I agree that
> PQconnectPoll() has grown beyond the point of making it easy to
> maintain. I am wondering which approach we could take when it comes
> to simplify something like that. Attempting to reduce the number of
> flags stored in PGconn would be one. The second may be to split the
> internal logic into more functions, for each state we are going
> through? The first may lead to an even cleaner logic for the second
> point.
Yeah, a mixture of both might be helpful -- the first to reduce the
inputs to the state machine; the second to reduce interdependencies
between cases, the distance of the potential goto jumps, and the
number of state machine outputs. (When cases are heavily dependent on
each other, probably best to handle them in the same function?)
Luckily it looks like the current machine is usually linear.
Thanks,
--Jacob
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2023-02-17 17:01:54 | Re: Move defaults toward ICU in 16? |
Previous Message | David G. Johnston | 2023-02-17 16:53:35 | Re: psql: Add role's membership options to the \du+ command |