Re: Add http connection service file functionality
Andrew Jackson <andrewjackson947@gmail.com>
From: Andrew Jackson <andrewjackson947@gmail.com>
To: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2026-03-25T01:43:49Z
Lists: pgsql-hackers
Attachments
- 0001-Add-http-connection-service-file-functionality.patch (text/x-patch) patch 0001
Hello, Apologies, forgot to attach the past and the links to the references i made. [0]: https://www.postgresql.org/docs/current/libpq-ldap.html [1]: https://www.postgresql.org/message-id/flat/CAKK5BkFOFGfKJNbTuYBvE0PfpHmW8iZEmdNogaCYqjAOhtNgDg@mail.gmail.com [2]: https://www.postgresql.org/message-id/flat/CAKK5BkESSc69sp2TiTWHvvOHCUey0rDWXSrR9pinyRqyfamUYg@mail.gmail.com [3]: https://www.postgresql.org/message-id/AM9PR09MB49008B02CDF003054D5D4E00977DA@AM9PR09MB4900.eurprd09.prod.outlook.com Thanks Andrew Jackson On Tue, Mar 24, 2026 at 8:13 PM Andrew Jackson <andrewjackson947@gmail.com> wrote: > > Hello, > > This patch adds an exported function to the libpq-oauth shared object > file that uses libcurl to look up connection service files > from an HTTP address instead of just on the local filesystem. > The goal here is to provide the ability for managed service > operators a single source of truth for connection details. > This enables a form of built-in libpq service discovery > format. This would allow administrators to add, remove, and > change hosts in multi host connection strings without > coordinating with every end user who may hardcode their > connection strings in a lot of different places. > > Currently libpq has functionality which accomplishes some of > the above by allowing entry of connection parameters into > LDAP servers[0], though this cannot be specified directly in > a connection string (though there is a patch that adds this > functionality [1]). Another potential issue here is that > setting up LDAP infrastructure is a lot less accessible to > many administrators than setting up an HTTP web server. > > The current state of this patch is very rough and is being > presented as more of a RFC than anything else. > Some obvious issues: > 1. Lots of duplicated logic between the parse_service_file_curl > and parseServiceFile. > 2. Bundling this functionality in with libpq-oauth.so seems odd. > It would probably make more sense to rename libpq-oauth.so to > libpq-oauth.so to libpq-libcurl.so or create an entirely new > .so file for this logic. > > Despite these shortcomings this approach may be a more natural > alternative to previous attempts [2, 3] at allowing administrators > to mix read-only/read-write nodes into overloaded A records. > > Would appreciate any feedback. > > Thanks, > Andrew Jackson