Re: [PATCH] Support reading large objects with pg_read_all_data

From: Nitin Motiani <nitinmotiani(at)google(dot)com>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: Dilip Kumar <dilipbalaut(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] Support reading large objects with pg_read_all_data
Date: 2026-02-24 02:06:45
Message-ID: CAH5HC97pHU0Co9A=8RQ2nE0=Jq75RYQJ=msmH_GWbqeyqBeS=A@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Here's what I have staged for commit. I didn't understand the reasoning
> behind not giving pg_write_all_data privileges on large objects.

Thanks Nathan. My thinking behind this was that even without these
changes, the 'select *' on the large object table worked for
pg_read_all_data so providing access to functions like lo_get seemed
consistent with that behaviour. But for pg_write_all_data, that wasn't
the case so I thought it might be safer not to provide access.

> commit message mentions that "granting write access would imply write
> permissions on a system catalog" (which I assume is referring to
> pg_largeobject), but if granting UPDATE on a large object is sufficient to
> allow updating portions of that catalog, then I see no reason to be so
> strict with pg_write_all_data. It still doesn't allow updating the catalog
> directly.
>

Thanks for the explanation and taking care of this.

Regards,
Nitin Motiani
Google

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2026-02-24 02:08:56 Re: pgsql: libpq: Grease the protocol by default
Previous Message John Naylor 2026-02-24 02:01:51 Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?