Feedback-ID: ie0a040ee:Fastmail
Message-ID: <cf349b4e-aa59-46af-a3ec-73157cb37116@eisentraut.org>
Date: Wed, 12 Feb 2025 15:55:23 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PoC] Federated Authn/z with OAUTHBEARER
To: Jacob Champion <jacob.champion@enterprisedb.com>,
 Daniel Gustafsson <daniel@yesql.se>
Cc: Antonin Houska <ah@cybertec.at>,
 PostgreSQL Hackers <pgsql-hackers@postgresql.org>
References: <d1b467a78e0e36ed85a09adf979d04cf124a9d4b.camel@vmware.com>
 <54c008ad-1c23-47d8-ba6c-bed98a39c31c@eisentraut.org>
 <CAOYmi+mEkXu9Jfg9v-5z9DmBCRCMS2dt43Z=TCbgVkbrqJXxRg@mail.gmail.com>
 <06102deb-00ef-431d-a3ea-65afb246700a@eisentraut.org>
 <CAOYmi+kZAka0sdxCOBxsQc2ozEZGZKHWU_9nrPXg3sG1NJ-zJw@mail.gmail.com>
 <CE4D545A-7583-4FA9-98DD-57388CCC006F@yesql.se>
 <CAOYmi+kQFrKGmC0=Um-QryU1fvCAOC2bpjcz-4rxgLrp69mSOg@mail.gmail.com>
 <39A09EC8-2D72-4130-8C3E-8F3D1CC69A12@yesql.se>
 <CAOYmi+=K3BBRXwvJpt5D_4nK_EimCJBj7a42maACszsQC3=t9w@mail.gmail.com>
 <55EA9E76-9866-486C-9C7F-C5E8B071C50E@yesql.se>
 <CAOYmi+kJqzo6XsR9TEhvVfeVNQ-TyFM5LATypm9yoQVYk=4Wrw@mail.gmail.com>
 <35CBB6AD-B847-4C26-9A7B-019279F280C8@yesql.se>
 <9F184CFE-ED8D-4B86-9529-F07821108C93@yesql.se>
 <CAOYmi+nHG7oy+ybHH72WjiXAQG3tE6v_at-K9ebRy2oqo92V+A@mail.gmail.com>
 <C35FE624-DEF8-4359-9C7E-ED974A10CC29@yesql.se>
 <CAOYmi+mFZsExAYWy-bS9=yki_fWC+MC0MufpEZ_SycrbCAJrEg@mail.gmail.com>
Content-Language: en-US
From: Peter Eisentraut <peter@eisentraut.org>
In-Reply-To: <CAOYmi+mFZsExAYWy-bS9=yki_fWC+MC0MufpEZ_SycrbCAJrEg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/cf349b4e-aa59-46af-a3ec-73157cb37116%40eisentraut.org>
Precedence: bulk

On 08.02.25 02:56, Jacob Champion wrote:
> On Fri, Feb 7, 2025 at 12:12 PM Daniel Gustafsson<daniel@yesql.se> wrote:
>> Is it really enough to do this at build time?  A very small percentage of users
>> running this will also be building their own libpq so the warning is lost on
>> them.  That being said, I'm not entirely sure what else we could do (bleeping a
>> warning every time is clearly not userfriendly) so maybe this is a TODO in the
>> code?
> I've added a TODO back. At the moment, I don't have any good ideas; if
> the user isn't building libpq, they're not going to be able to take
> action on the warning anyway, and for many use cases they're probably
> not going to care.

This just depends on how people have built their libcurl, right?

Do we have any information whether the async-dns-free build is a common 
configuration?