MIME-Version: 1.0
References: 
 <CADsUR0B9bcJQKYHyUMnWcODGzF5+AdeToawULkkTKfrq32Z-8w@mail.gmail.com>
 <64f1c69a-ceff-4b17-8298-58f255d075fc@gmail.com>
 <dde00623-b8e0-421b-a3f7-b149768894ef@app.fastmail.com>
 <fab6a5f3-df9f-4bd7-b2ac-434a17303547@gmail.com>
 <7f6e0ff9-05e9-4664-9c71-d9dd744362b9@gmail.com>
 <138cfd8c-b305-4303-9700-bc53ff4fb926@eisentraut.org>
 <CAKAnmmKgYqavU6xUPKgeOwOY0P9EycCmm339+PLaL5f4AQ9fNQ@mail.gmail.com>
 <CAGECzQSmRUw9qfpeJFApnhywH_FmLRCHKt4Gncn7zC-MDffchQ@mail.gmail.com>
In-Reply-To: 
 <CAGECzQSmRUw9qfpeJFApnhywH_FmLRCHKt4Gncn7zC-MDffchQ@mail.gmail.com>
From: Isaac Morland <isaac.morland@gmail.com>
Date: Mon, 23 Mar 2026 07:04:18 -0400
Message-ID: 
 <CAMsGm5fuHSvjCYuR3qyFWkbQGMjT2AS7ZJ8rrU+MjT7YzO2e_A@mail.gmail.com>
Subject: Re: Read-only connection mode for AI workflows.
To: Jelte Fennema-Nio <postgres@jeltef.nl>
Cc: Greg Sabino Mullane <htamfids@gmail.com>,
 Peter Eisentraut <peter@eisentraut.org>,
	Andrei Lepikhov <lepihov@gmail.com>, Jack Bonatakis <jack@bonatak.is>,
	pgsql-hackers <pgsql-hackers@postgresql.org>,
	Bruce Momjian <bruce.momjian@enterprisedb.com>,
 Andres Freund <andres@anarazel.de>
Content-Type: multipart/alternative; boundary="000000000000a8dc93064daeff3e"
Archived-At: 
 <https://www.postgresql.org/message-id/CAMsGm5fuHSvjCYuR3qyFWkbQGMjT2AS7ZJ8rrU%2BMjT7YzO2e_A%40mail.gmail.com>
Precedence: bulk

--000000000000a8dc93064daeff3e
Content-Type: text/plain; charset="UTF-8"

On Mon, 23 Mar 2026 at 05:10, Jelte Fennema-Nio <postgres@jeltef.nl> wrote:

> On Fri, 20 Mar 2026 at 13:33, Greg Sabino Mullane <htamfids@gmail.com>
> wrote:
> > I'm a +1 to the cluster-wide change, and a -1 to the per-connection idea
> that started this thread, because I still don't see the need for it when we
> have an existing roles/permissions system that gets the job done. You want
> your untrusted agent to read from your database? Create a specific role for
> that. If our existing per-role access controls are not sufficient, improve
> them.
>
> I think they are insufficient for two reasons:
> 1. Afaik there's no simple way to take an existing role and create a
> new role from it that only has the read permissions of the original
> role. Especially if you want those permissions to stay in sync between
> the roles.
>

I don't think it's possible even in principle. As soon as the supposedly
read-only role calls a security definer function, the session is no longer
operating with the permissions of the supposedly read-only role.

I think what is wanted is, in effect, very close to the ability to pretend
that one is connected to a replica rather than the primary, What is
requested already exists in a sense through the use of replication, but
only at the entire instance level, not one session. In other words, what
you suggest below, although it might be interesting to think about whether
there are any other settings that would be useful to lock down in this
fashion:

I think the best way to address this thread is to have a way to "lock"
> settings down, like discussed in this thread[1]. Then a user could
> simply run the sql to lock down the transaction_read_only and get a
> read-only connection that it could give to the LLM.
>

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

<div dir=3D"ltr"><div dir=3D"ltr">On Mon, 23 Mar 2026 at 05:10, Jelte Fenne=
ma-Nio &lt;<a href=3D"mailto:postgres@jeltef.nl">postgres@jeltef.nl</a>&gt;=
 wrote:<br></div><div class=3D"gmail_quote gmail_quote_container"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-le=
ft:1ex">On Fri, 20 Mar 2026 at 13:33, Greg Sabino Mullane &lt;<a href=3D"ma=
ilto:htamfids@gmail.com" target=3D"_blank">htamfids@gmail.com</a>&gt; wrote=
:<br>
&gt; I&#39;m a +1 to the cluster-wide change, and a -1 to the per-connectio=
n idea that started this thread, because I still don&#39;t see the need for=
 it when we have an existing roles/permissions system that gets the job don=
e. You want your untrusted agent to read from your database? Create a speci=
fic role for that. If our existing per-role access controls are not suffici=
ent, improve them.<br>
<br>
I think they are insufficient for two reasons:<br>
1. Afaik there&#39;s no simple way to take an existing role and create a<br=
>
new role from it that only has the read permissions of the original<br>
role. Especially if you want those permissions to stay in sync between<br>
the roles.<br>
</blockquote><div><br></div><div>I don&#39;t think it&#39;s possible even i=
n principle. As soon as the supposedly read-only role calls a security defi=
ner function, the session is no longer operating with the permissions of th=
e supposedly read-only role.</div><div><br></div><div>I think what is wante=
d is, in effect, very close to the ability to pretend that one is connected=
 to a replica rather than the primary, What is requested already exists in=
=C2=A0a sense through the use of replication, but only at the entire instan=
ce level, not one session. In other words, what you suggest below, although=
 it might be interesting to think about whether there are any other setting=
s that would be useful to lock down in this fashion:</div><div><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pad=
ding-left:1ex">
I think the best way to address this thread is to have a way to &quot;lock&=
quot;<br>
settings down, like discussed in this thread[1]. Then a user could<br>
simply run the sql to lock down the transaction_read_only and get a<br>
read-only connection that it could give to the LLM.<br>
</blockquote></div></div>

--000000000000a8dc93064daeff3e--