| From: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Timo Stolz <timo(dot)stolz(at)nullachtvierzehn(dot)de>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>, Jonas Reinsch <jonas(dot)reinsch(at)pitchview(dot)de>, Laura Schlimmer <laura(dot)schlimmer(at)pitchview(dot)de> |
| Subject: | 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 |
| Date: | 2022-07-21 07:19:04 |
| Message-ID: | CAEZATCUy6Uqtv=_PYbc-CmpkfF2vBxE0ZhyXRr_u1nt=wjHCkw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Wed, 20 Jul 2022 at 21:54, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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