Re: If a row-level security policy contains a set returning function, pg_dump returns an incorrect serialization of that policy if the return type of the function was altered
От | Dean Rasheed |
---|---|
Тема | Re: If a row-level security policy contains a set returning function, pg_dump returns an incorrect serialization of that policy if the return type of the function was altered |
Дата | |
Msg-id | CAEZATCUy6Uqtv=_PYbc-CmpkfF2vBxE0ZhyXRr_u1nt=wjHCkw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: If a row-level security policy contains a set returning function, pg_dump returns an incorrect serialization of that policy if the return type of the function was altered (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: If a row-level security policy contains a set returning function, pg_dump returns an incorrect serialization of that policy if the return type of the function was altered
|
Список | pgsql-bugs |
On Wed, 20 Jul 2022 at 21:54, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > This has nothing particularly to do with RLS policies; you can > reproduce the same problem with any stored query that selects from a > function-returning-composite, for instance a view. > Yep, I reached the same conclusion. > What we have to do here is to suppress the aliases for any since-dropped > columns, while keeping the live ones. That's slightly finicky, but there > is existing code that can get the job done. ruleutils just wasn't > considering the possibility that function RTEs might have this problem. > Agreed. I even came up with a similar patch, but your version looks better. > The larger issue that this touches on is that we don't prevent you from > dropping the composite type's column even when the query using the > dependent function has hard references to that column (e.g, it's actually > output by the view). Maybe sometime somebody ought to work on tightening > that up. In the meantime though, it's bad for EXPLAIN or pg_dump to fail > altogether on such cases, so I propose the behavior shown in the attached > patch. > +1. LGTM. Regards, Dean
В списке pgsql-bugs по дате отправления: