Re: Read-only connection mode for AI workflows.

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Andrei Lepikhov <lepihov(at)gmail(dot)com>
Cc: Jack Bonatakis <jack(at)bonatak(dot)is>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Read-only connection mode for AI workflows.
Date: 2026-03-17 16:31:56
Message-ID: abmB_B-PisvwPpsc@momjian.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 17, 2026 at 09:52:24AM -0400, Bruce Momjian wrote:
> On Tue, Mar 17, 2026 at 11:04:25AM +0100, Andrei Lepikhov wrote:
> > On 16/3/26 22:25, Bruce Momjian wrote:
> > > On Mon, Mar 16, 2026 at 10:01:22PM +0100, Andrei Lepikhov wrote:
> > > > > I do think the underlying problem of safely exposing databases to
> > > > > automated agents is becoming increasingly common, so it seems like a
> > > > > useful area to explore.
> > >
> > > I agree the need a read-only sessions is going to get more urgent with
> > > MCP. Why doesn't the community code have a read-only session option
> > > that can't be changed?
> >
> > The pg_readonly project aims to answer this question: if it is easy and
> > cheap to implement as an extension, why do we need to touch the core?
>
> I think it is a fundamental feature the database should have by default.

I now see that pg_readonly is cluster-wide:

https://github.com/pierreforstmann/pg_readonly

I agree we should have a per-session control that cannot be changed.

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com

Do not let urgent matters crowd out time for investment in the future.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2026-03-17 16:34:04 Re: Add starelid, attnum to pg_stats and leverage this in pg_dump
Previous Message Jacob Champion 2026-03-17 16:25:41 Re: Improve OAuth discovery logging