Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications
От | Tom Lane |
---|---|
Тема | Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications |
Дата | |
Msg-id | 2522013.1725733293@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications
|
Список | pgsql-bugs |
Basha <Basha@maxcontact.com> writes: > The fix in PG16.4, entirely prevents changes to pg_database, Is > there any possibility of a more targeted approach. If we allow pg_database to be replaced by a view, we have the same hazard that the security patch means to fix: namely that the view might be hostile, or even just that it might innocently lie to us resulting in incorrect pg_dump output. I'm uninterested in poking a hole in that security defense. I don't think we've ended the discussion on whether to remove the check that's preventing using RLS instead. But even if we choose to do that, you're still depending on something that's not supported and might break again in future. To be absolutely clear: *nothing* you might use allow_system_table_mods to do is considered supported for production purposes, and we will not apologize for breaking it. You really ought to think about how badly do you need to hide the existence of other databases. It seems like a mighty low-priority requirement from here, especially if you can't also hide the existence of other roles. regards, tom lane
В списке pgsql-bugs по дате отправления: