Greetings, * Magnus Hagander (mag...@hagander.net) wrote: > On Fri, Aug 28, 2020 at 2:38 PM Stephen Frost <sfr...@snowman.net> wrote: > > * Magnus Hagander (mag...@hagander.net) wrote: > > > Without having actually looked at the code, definite +1 for this feature. > > > It's much requested... > > > > Thanks. > > > > > But, should we also have a pg_write_all_data to go along with it? > > > > Perhaps, but could certainly be a different patch, and it'd need to be > > better defined, it seems to me... read_all is pretty straight-forward > > (the general goal being "make pg_dumpall/pg_dump work"), what would > > write mean? INSERT? DELETE? TRUNCATE? ALTER TABLE? System catalogs? > > Well, it's pg_write_all_*data*, so it certainly wouldn't be alter table or > system catalogs. > > I'd say insert/update/delete yes. > > TRUNCATE is always an outlier.Given it's generally classified as DDL, I > wouldn't include it.
Alright, that seems like it'd be pretty easy. We already have a check in pg_class_aclmask to disallow modification of system catalogs w/o being a superuser, so we should be alright to add a similar check for insert/update/delete just below where I added the SELECT check. > > Doesn't seem like you could just declare it to be 'allow pg_restore' > > either, as that might include creating untrusted functions, et al. > > No definitely not. That wouldn't be the usecase at all :) Good. :) > (and fwiw to me the main use case for read_all_data also isn't pg_dump, > because most people using pg_dump are already db owner or higher in my > experience. But it is nice that it helps with that too) Glad to have confirmation that there's other use-cases this helps with. I'll post an updated patch with that added in a day or two. Thanks, Stephen
signature.asc
Description: PGP signature
