|From:||Stephen Frost <sfrost(at)snowman(dot)net>|
|To:||Magnus Hagander <magnus(at)hagander(dot)net>|
|Cc:||PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: New default role- 'pg_read_all_data'|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
* Stephen Frost (sfrost(at)snowman(dot)net) wrote:
> * Magnus Hagander (magnus(at)hagander(dot)net) wrote:
> > On Fri, Aug 28, 2020 at 2:38 PM Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > > * Magnus Hagander (magnus(at)hagander(dot)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.
Here's that updated patch, comments welcome.
|Next Message||Tatsuro Yamada||2020-08-30 23:56:52||Re: list of extended statistics on psql|
|Previous Message||Tom Lane||2020-08-30 21:59:39||Re: Compatible defaults for LEAD/LAG|