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