From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: New default role- 'pg_read_all_data' |
Date: | 2020-08-28 12:50:25 |
Message-ID: | CABUevEx5akfNeSrHsinCRWfXzSYFNRTnBc4vHKMgum8hLrr=yg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Aug 28, 2020 at 2:38 PM Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> Greetings,
>
> * 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.
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 :)
(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)
--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
From | Date | Subject | |
---|---|---|---|
Next Message | Isaac Morland | 2020-08-28 12:51:06 | Re: New default role- 'pg_read_all_data' |
Previous Message | Jakub Wartak | 2020-08-28 12:43:52 | Re: Handing off SLRU fsyncs to the checkpointer |