public inbox for [email protected]  

help / color / mirror / Atom feed

From: Bruce Momjian <[email protected]>
To: Andrei Lepikhov <[email protected]>
Cc: Jack Bonatakis <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: Read-only connection mode for AI workflows.
Date: Tue, 17 Mar 2026 10:11:20 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <CADsUR0B9bcJQKYHyUMnWcODGzF5+AdeToawULkkTKfrq32Z-8w@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

On Tue, Mar 17, 2026 at 03:05:08PM +0100, Andrei Lepikhov wrote:
> On 17/3/26 14:52, 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.
> > 
> 
> Why wasn’t read-only mode set up like this from the start? - I haven’t seen
> any other DBMSs, aside from SQLite, offer this kind of guarantee.

I have no idea why.  I guess there just wasn't much demand, but now
there clearly is with MCP.

> If we want to move forward, it makes sense to use a session parameter and
> add backend code to prevent violations.

Agreed.

> Postgres architecture looks well-suited for this feature. However, the
> request is to block all backend changes, not just the usual XactReadOnly
> limitations, but also things like vacuum, etc (temporary tables?). Should we
> also consider cluster-wide restrictions?

No, I don't think cluster-wide is in demand, but I might be wrong.

-- 
  Bruce Momjian  <[email protected]>        https://momjian.us
  EDB                                      https://enterprisedb.com

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

view thread (20+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: Read-only connection mode for AI workflows.
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox