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

Timo Stolz <timo.stolz@nullachtvierzehn.de> writes:
> *Summary: 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 after the policy was created.*

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.

We even have a regression test case illustrating the current behavior :-(.
I guess nobody thought hard about the implications for dump-and-restore,
but I agree that they're bad.

> Instead of this, I would expect a serialization without an aliased FROM 
> clause, because that's how I wrote these policies in the first place.

You might expect that, but you won't get it.  As noted in ruleutils.c,

     * For a relation RTE, we need only print the alias column names if any
     * are different from the underlying "real" names.  For a function RTE,
     * always emit a complete column alias list; this is to protect against
     * possible instability of the default column names (eg, from altering
     * parameter names).  For tablefunc RTEs, we never print aliases, ...

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.

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.

(Even if somebody does add the necessary dependencies later, we'd still
need to cope with the situation in released branches, which might already
have broken views to cope with.)

			regards, tom lane