| From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
|---|---|
| To: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
| Cc: | Daniel Gustafsson <daniel(at)yesql(dot)se>, 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-09 16:17:31 |
| Message-ID: | 54c008ad-1c23-47d8-ba6c-bed98a39c31c@eisentraut.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 08.01.25 21:29, Jacob Champion wrote:
>>> It'd also couple clients against libpq-int.h, so they'd have to
>>> remember to recompile every release. I'm worried that'd cause a bunch
>>> of ABI problems...
>> Couldn't that function use PQsocket() to get at the actual socket from
>> the PGconn handle?
> It's an output parameter (i.e. the async callback is responsible for
> setting conn->altsock). Unless I've missed the point entirely, I don't
> think PQsocket() helps here.
Maybe it would work to just use plain "int" as the type here. Any
socket number must fit into int anyway in order for PQsocket() to be
able to return it. The way I understand Windows socket handles, this
should work.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Melanie Plageman | 2025-01-09 16:17:40 | Re: Adjusting hash join memory limit to handle batch explosion |
| Previous Message | Zhou, Zhiguo | 2025-01-09 16:03:46 | Re: [RFC] Lock-free XLog Reservation from WAL |