From: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
---|---|
To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
Cc: | Peter Eisentraut <peter(at)eisentraut(dot)org>, Antonin Houska <ah(at)cybertec(dot)at>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PoC] Federated Authn/z with OAUTHBEARER |
Date: | 2025-01-21 00:40:36 |
Message-ID: | CAOYmi+kQFrKGmC0=Um-QryU1fvCAOC2bpjcz-4rxgLrp69mSOg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jan 20, 2025 at 2:10 PM Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
> + /*
> + * The mechanism should have set up the necessary callbacks; all we
> + * need to do is signal the caller.
> + */
> + *async = true;
> + return STATUS_OK;
> Is it worth adding assertions here to ensure that everything has been set up
> properly to help when adding a new mechanism in the future?
Yeah, I think that'd be helpful.
> + /* Done. Tear down the async implementation. */
> + conn->cleanup_async_auth(conn);
> + conn->cleanup_async_auth = NULL;
> + Assert(conn->altsock == PGINVALID_SOCKET);
> In pqDropConnection() we set ->altsock to NULL
(I assume you mean PGINVALID_SOCKET?)
> just to be sure rather than
> assert that cleanup has done so. Shouldn't we be consistent in the
> expectation and set to NULL here as well?
I'm not opposed; I just figured that the following code might be a bit
confusing:
Assert(conn->altsock == PGINVALID_SOCKET);
conn->altsock = PGINVALID_SOCKET;
But I can add a comment to the assignment to try to explain. I don't
know what the likelihood of landing code that trips that assertion is,
but an explicit assignment would at least stop problems from
cascading.
--Jacob
From | Date | Subject | |
---|---|---|---|
Next Message | Jacob Champion | 2025-01-21 00:43:41 | Re: [PoC] Federated Authn/z with OAUTHBEARER |
Previous Message | Maciek Sakrejda | 2025-01-21 00:18:44 | Re: [PATCH] Add roman support for to_number function |