| 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.
| 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 |