| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
| 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 17:58:44 |
| Message-ID: | 130689.1658426324@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
> On Wed, 20 Jul 2022 at 21:54, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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.
Pushed, thanks for reviewing!
I think I'll go take a look at the missing-dependency aspect now.
I realized from checking the commit log that we've been putting
off doing that since 2014, if not before. Really should fix it.
regards, tom lane