Horton

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>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Dean Rasheed <dean.a.rasheed@gmail.com>
Cc: Timo Stolz <timo.stolz@nullachtvierzehn.de>, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>, Jonas Reinsch <jonas.reinsch@pitchview.de>, Laura Schlimmer <laura.schlimmer@pitchview.de>
Date: 2022-07-21T17:58:44Z
Lists: pgsql-bugs 
Dean Rasheed <dean.a.rasheed@gmail.com> writes:
> On Wed, 20 Jul 2022 at 21:54, Tom Lane <tgl@sss.pgh.pa.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

Commits

  1. Close old gap in dependency checks for functions returning composite.

  2. Fix ruleutils issues with dropped cols in functions-returning-composite.