MIME-Version: 1.0
References: <CAKAnmm+T-CEDLmRezWfH-7ZEsFfD_kU2KY1TgB288K+wprB_4Q@mail.gmail.com>
 <21076.1748617331@localhost> <CAKAnmmJ77jeYZGXPBxb75U52ojNRUoKd6Za-T26xNPCouUeV8g@mail.gmail.com>
 <2724612.1748655287@sss.pgh.pa.us> <CAKAnmm+RQbLFv1F35ZTRZfMRigwN0LN0KKRocLLpwSshBTZxvg@mail.gmail.com>
 <CAKAnmmLdrvdCMbAQbfiWY3q=zv+-11zZk+jweTRVCJrNL=aD4A@mail.gmail.com>
 <CAKAnmmKxP7bOO7QOLdSk8dYoUxFRus2XC1nEbk6En9GgV_4JbA@mail.gmail.com> <11894.1767966998@localhost>
In-Reply-To: <11894.1767966998@localhost>
From: Greg Sabino Mullane <htamfids@gmail.com>
Date: Fri, 9 Jan 2026 09:15:48 -0500
Message-ID: <CAKAnmm+-+2aZiK-wtwSCEpfOJbU7-PnwofByhr0F_XQB4wUJNw@mail.gmail.com>
Subject: Re: POC: Carefully exposing information without authentication
To: Antonin Houska <ah@cybertec.at>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, 
	"pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Content-Type: multipart/alternative; boundary="0000000000009eec5e0647f52bfa"
Archived-At: <https://www.postgresql.org/message-id/CAKAnmm%2B-%2B2aZiK-wtwSCEpfOJbU7-PnwofByhr0F_XQB4wUJNw%40mail.gmail.com>
Precedence: bulk

--0000000000009eec5e0647f52bfa
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 9, 2026 at 8:56=E2=80=AFAM Antonin Houska <ah@cybertec.at> wrot=
e:

> 1. Add a new field to the PGconn structure


This kind of defeats one of the major strengths of this patch, which is
allowing systems that don't speak the protocol to get at this information.


> Regarding configuration, I'd prefer a single GUC. The value can be a
> comma-separated list of keywords, each representing particular piece of
> information to be exposed.
>

Yes, I could see some advantages to that, although I still like the
simplicity of separate boolean values. I've no strong feelings either way.
Let's see if others weigh in.

Thanks for looking over this patch!

Cheers,
Greg

--0000000000009eec5e0647f52bfa
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Fri, Jan 9, 2026 at 8:56=E2=80=AFAM An=
tonin Houska &lt;<a href=3D"mailto:ah@cybertec.at">ah@cybertec.at</a>&gt; w=
rote:</div><div class=3D"gmail_quote gmail_quote_container"><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">
1. Add a new field to the PGconn structure</blockquote><div><br></div><div>=
This kind of defeats one of the major strengths of this patch, which is all=
owing systems that don&#39;t speak the protocol to get at this information.=
=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex">Regarding configuration, I&#39;d prefer a single GUC. The value can be =
a comma-separated list of keywords, each representing particular piece of i=
nformation to be exposed.<br></blockquote><div><br></div><div>Yes, I could =
see some advantages to that, although=C2=A0I still like the simplicity of s=
eparate boolean values. I&#39;ve no strong feelings either way. Let&#39;s s=
ee if others weigh in.</div><div><br></div><div>Thanks for looking=C2=A0ove=
r this patch!</div><div><br></div><div>Cheers,</div></div><div dir=3D"ltr" =
class=3D"gmail_signature"><div dir=3D"ltr"><div>Greg</div><div><br></div></=
div></div></div>

--0000000000009eec5e0647f52bfa--